Hibernate Criteria restituisce i figli più volte con FetchType.EAGER

Ho una Orderclasse che ha un elenco di OrderTransactionse l'ho mappata con una mappatura Hibernate uno-a-molti in questo modo:

@OneToMany(targetEntity = OrderTransaction.class, cascade = CascadeType.ALL)
public List<OrderTransaction> getOrderTransactions() {
    return orderTransactions;
}

Questi Orderhanno anche un campo orderStatus, che viene utilizzato per filtrare con i seguenti criteri:

public List<Order> getOrderForProduct(OrderFilter orderFilter) {
    Criteria criteria = getHibernateSession()
            .createCriteria(Order.class)
            .add(Restrictions.in("orderStatus", orderFilter.getStatusesToShow()));
    return criteria.list();
}

Funziona e il risultato è come previsto.

Ora ecco la mia domanda : perché, quando imposto il tipo di recupero esplicitamente su EAGER, le Orders vengono visualizzate più volte nell'elenco risultante?

@OneToMany(targetEntity = OrderTransaction.class, fetch = FetchType.EAGER, cascade = CascadeType.ALL)
public List<OrderTransaction> getOrderTransactions() {
    return orderTransactions;
}

Come dovrei cambiare il mio codice Criteri per ottenere lo stesso risultato con la nuova impostazione?

Questo è in realtà il comportamento previsto se ho capito correttamente la tua configurazione.

Ottieni la stessa Orderistanza in uno qualsiasi dei risultati, ma poiché ora stai facendo un join con OrderTransaction, deve restituire la stessa quantità di risultati che restituirà un normale sql join

Quindi in realtà dovrebbe apparire più volte. questo è spiegato molto bene dallo stesso autore (Gavin King) qui : spiega sia perché, sia come ottenere risultati distinti

Hibernate non restituisce risultati distinti per una query con il recupero del join esterno abilitato per una raccolta (anche se utilizzo la parola chiave distinta)? Innanzitutto, è necessario comprendere SQL e come funzionano gli OUTER JOIN in SQL. Se non comprendi e comprendi appieno gli outer join in SQL, non continuare a leggere questo articolo delle domande frequenti ma consulta un manuale o un'esercitazione SQL. Altrimenti non capirai la seguente spiegazione e ti lamenterai di questo comportamento sul forum di Hibernate.

Esempi tipici che potrebbero restituire riferimenti duplicati dello stesso oggetto Order:

List result = session.createCriteria(Order.class)
                    .setFetchMode("lineItems", FetchMode.JOIN)
                    .list();

---

<class name="Order">
    ...
    <set name="lineItems" fetch="join">

---

List result = session.createCriteria(Order.class)
                       .list();
List result = session.createQuery("select o from Order o left join fetch o.lineItems").list();

Tutti questi esempi producono la stessa istruzione SQL:

SELECT o.*, l.* from ORDER o LEFT OUTER JOIN LINE_ITEMS l ON o.ID = l.ORDER_ID

Vuoi sapere perché ci sono i duplicati? Guarda il set di risultati SQL, Hibernate non nasconde questi duplicati sul lato sinistro del risultato del join esterno ma restituisce tutti i duplicati della tabella guida. Se hai 5 ordini nel database e ogni ordine ha 3 voci, il gruppo di risultati sarà di 15 righe. L'elenco dei risultati Java di queste query avrà 15 elementi, tutti di tipo Order. Solo 5 istanze di Order verranno create da Hibernate, ma i duplicati del set di risultati SQL vengono conservati come riferimenti duplicati a queste 5 istanze. Se non capisci quest'ultima frase, devi leggere su Java e la differenza tra un'istanza sull'heap Java e un riferimento a tale istanza.

(Perché un join esterno sinistro? Se avessi un ordine aggiuntivo senza elementi pubblicitari, il set di risultati sarebbe 16 righe con NULL che riempie il lato destro, dove i dati dell'elemento pubblicitario sono per l'altro ordine. Vuoi ordini anche se non hanno elementi pubblicitari, giusto? In caso contrario, utilizza un inner join fetch nel tuo HQL).

Hibernate non filtra questi riferimenti duplicati per impostazione predefinita. Alcune persone (non tu) lo vogliono davvero. Come puoi filtrarli?

Come questo:

Collection result = new LinkedHashSet( session.create*(...).list() );

Oltre a quanto menzionato da Eran, un altro modo per ottenere il comportamento desiderato, è impostare il trasformatore del risultato:

criteria.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);

provare

@Fetch (FetchMode.SELECT) 

per esempio

@OneToMany(targetEntity = OrderTransaction.class, fetch = FetchType.EAGER, cascade = CascadeType.ALL)
@Fetch (FetchMode.SELECT)
public List<OrderTransaction> getOrderTransactions() {
return orderTransactions;

}

Non utilizzare List e ArrayList ma Set e HashSet.

@OneToMany(targetEntity = OrderTransaction.class, cascade = CascadeType.ALL)
public Set<OrderTransaction> getOrderTransactions() {
    return orderTransactions;
}

Utilizzando Java 8 e Streams aggiungo nel mio metodo di utilità questa dichiarazione di ritorno:

return results.stream().distinct().collect(Collectors.toList());

I flussi rimuovono i duplicati molto velocemente. Uso l'annotazione nella mia classe Entity in questo modo:

@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
@JoinTable(name = "STUDENT_COURSES")
private List<Course> courses;

Penso che sia meglio nella mia app utilizzare la sessione nel metodo in cui ho bisogno di dati dal database. Closse session quando ho finito. Ovviamente ha impostato la mia classe Entity per utilizzare il tipo di recupero lento. Vado al refactoring.

Ho lo stesso problema per recuperare 2 raccolte associate: l'utente ha 2 ruoli (Set) e 2 pasti (Elenco) e i pasti sono duplicati.

@Table(name = "users")
public class User extends AbstractNamedEntity {

   @CollectionTable(name = "user_roles", joinColumns = @JoinColumn(name = "user_id"))
   @Column(name = "role")
   @ElementCollection(fetch = FetchType.EAGER)
   @BatchSize(size = 200)
   private Set<Role> roles;

   @OneToMany(fetch = FetchType.LAZY, mappedBy = "user")
   @OrderBy("dateTime DESC")
   protected List<Meal> meals;
   ...
}

DISTINCT non aiuta (query DATA-JPA):

@EntityGraph(attributePaths={"meals", "roles"})
@QueryHints({@QueryHint(name= org.hibernate.jpa.QueryHints.HINT_PASS_DISTINCT_THROUGH, value = "false")}) // remove unnecessary distinct from select
@Query("SELECT DISTINCT u FROM User u WHERE u.id=?1")
User getWithMeals(int id);

Finalmente ho trovato 2 soluzioni:

1. Cambia elenco in LinkedHashSet
2. Usa EntityGraph solo con il campo "meal" e digita LOAD, che carica i ruoli come hanno dichiarato (EAGER e da BatchSize = 200 per evitare problemi N + 1):

Soluzione finale:

@EntityGraph(attributePaths = {"meals"}, type = EntityGraph.EntityGraphType.LOAD)
@Query("SELECT u FROM User u WHERE u.id=?1")
User getWithMeals(int id);

Invece di usare hack come:

• Set invece di List
• criteria.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);

che non modificano la tua query sql, possiamo usare (citando le specifiche JPA)

q.select(emp).distinct(true);

che modifica la query sql risultante, avendo così un file DISTINCT.

Non sembra un ottimo comportamento applicare un outer join e portare risultati duplicati. L'unica soluzione rimasta è filtrare il nostro risultato utilizzando i flussi. Grazie java8 che ci ha fornito un modo più semplice per filtrare.

return results.stream().distinct().collect(Collectors.toList());