JPQL: Inner Join senza i record duplicati

Sotto è una domanda che, apparentemente, era parte di un esame ufficiale da Sole:

Un Lettore di entità non ha un uno-a-molti, relazione bidirezionale con un
Prenota entità. Due Reader entità sono persistenti, ognuna con Libro
entità ad essi associati. Per esempio, il lettore di 1 ha un libro e
prenota b, mentre reader 2 ha libro c e libro d’. La query che restituisce un
Raccolta di meno di quattro elementi?
A. SELEZIONARE b.lettore DAL Libro b
B. SELEZIONARE r DAL Libro b INNER JOIN b.lettore di r
C. SELEZIONARE r DA Reader r INNER JOIN r.libri b
D. SELEZIONARE r dal Libro b LEFT JOIN b.lettore di r LEFT JOIN FETCH r.libri

Dato risposta è C, che, credo, non è corretto. Da quello che ho capito, SQL con inner join delle due tabelle verranno generati dal provider JPA. Pertanto, in tutti i casi avremo 4 record. Ho eseguito un test con uno-a-molti relazione e duplicati sono stati inclusi.

Che è sbagliato, me o Sole?

Ho eseguito il test con l’Ibernazione, e c’erano duplicati così. select distinct r può essere utilizzato per rimuovere i duplicati.
Grazie per il controllo. Vorrei utilizzare SELEZIONARE r DAL Lettore di r, DOVE r.libri è VUOTO per ottenere unici lettori che hanno preso in prestito libri… Però, sostengono C è la risposta giusta.
sicuramente, NON È VUOTO
Ho controllato il tutorial da parte di Oracle e ha confuso ancora di più: >SELECT DISTINCT p DAL Giocatore p, (p.squadre) t Dati recuperati: Tutti i giocatori che fanno parte di una squadra. Si può anche utilizzare l’istruzione JOIN per scrivere la stessa query: SELECT DISTINCT p DAL Giocatore p JOIN p.squadre di t la query può anche essere riscritta come: SELECT DISTINCT p DAL Giocatore p DOVE p.la squadra NON È VUOTO Perché utilizzare DISTINTI in quest’ultimo caso?

OriginaleL’autore Moose on the Loose | 2011-11-20

2 Replies
  1. 14

    Risposta da Mike Keith, EJB 3.0 co-specifica di piombo:

    Ci sono un paio di dichiarazioni relative ai duplicati di spec.

    1. Il JOIN FETCH è una variazione del JOIN, ma è stato JOIN simili semantica applicare (tranne che di ulteriori dati è selezionata). La spec (sezione 4.4.5.3 JPA v2.0) dà un esempio di duplicare Dipartimento di righe restituito nonostante il fatto che il Dipendente oggetti non sono nella clausola select.

    2. Più diretto riferimento nel SELEZIONARE la sezione (sezione 4.8 del JPA v2.0), dove si afferma chiaramente

    “Se viene omessa, valori duplicati non vengono eliminati.”

    Molti JPA fornitori di fatto rimuovere i duplicati per un paio di motivi:

    a) la Comodità degli utenti, perché alcuni utenti non sono informato abbastanza in SQL e non sono in attesa di loro
    b) non Vi è in genere non è un caso che richiedono dups
    c) possono essere aggiunti a un set di risultati e se l’identità dell’oggetto è mantenuto dups eliminati automaticamente

    OriginaleL’autore Moose on the Loose

  2. 0

    C è corretta, si unisce a ToMany relazioni non dovrebbe tornare duplicati. L’APP provider dovrebbe utilizzare automaticamente un distinto per filtrare questi fuori. Credo che questo è ciò che la spec richiede, anche se può essere uno di quelli meno ben definite aree di spec.

    Se un join fetch è utilizzato, l’credo che la spec in realtà richiede i duplicati essere restituiti. Che è strano, perché vuoi a tutti i duplicati. Se si mette una distinta su un join fetch, verrà filtrato (in memoria, come tutte le righe devono essere selezionati).

    Questo è come EclipseLink funziona comunque.

    Tutti gli altri casi di selezionare i Libri non lettori, in modo da ottenere i duplicati, C seleziona i Lettori, quindi non dovrebbe avere duplicati.

    Giacomo, ho sfogliato specifica e non è riuscito a trovare il requisito di eliminare i duplicati. Tuttavia, in toplink (eclipse-link) docs faccio vedere di menzionare la rimozione di duplicati: Join reading can result in returning duplicate data if a one-to-many or a shared one-to-one relationship is joined. Although TopLink correctly filters the duplicate results from the object result, the duplicate data still must be fetched from the database and can degrade performance, especially if multiple one-to-many relationships are joined. si Potrebbe si prega di eseguire query simile utilizzando JPA e condividere il risultato.

    OriginaleL’autore James

Lascia un commento