Utilizzo di getGeneratedKeys con inserimenti batch in MySQL con Connector/J

Question

Utilizzando Connector/J, desidero eseguire un inserimento batch in una tabella principale seguita da un inserimento batch in una tabella dei dettagli (PreparedStatement.executeBatch() per entrambi). Non ho trovato molte informazioni online, quindi cerco feedback dalle persone che hanno esperienza con questo.

1. Posso usare Statement.getGeneratedKeys() per ottenere gli ID dei nuove righe inserite nella tabella master in modo che io possa utilizzarli come chiavi esterne nelle dettaglio inserti?

2. Cosa succede se non ogni query ha provocato un inserto (ad esempio c'è stato un insert ignore o insert ... on duplicate key update query)? Riceverò una riga in Statement.getGeneratedKeys() per ogni istruzione o solo per quelli nuovi?

3. Quali saranno Statement.getGeneratedKeys() ritorno c'è un errore con uno dei anagrafiche inseriti, e continueBatchOnError è impostato su true nella stringa di connessione?

4. Ci sono differenze nel comportamento correlato tra Connector/J versioni 5.0.x vs 5.5.x? Che dire di MySQL 5.0 contro 5.1?

5. C'è qualche altro problema o trucchetto di cui dovrei essere a conoscenza?

6. C'è un modo migliore per farlo?

Answer 1

Bene, ho eseguito alcuni test. Con connettore/J 5.1 e MySQL 5.1.42, osservo quanto segue:

1. Statement.getGeneratedKeys() lavori come previsto per inserti

2. Se una riga è stata inserita o aggiornata (la matrice conteggio di aggiornamento restituito da executeBatch() ritorni '1' o '2'), Statement.getGeneratedKeys() avrà la chiave per quella riga. Se la riga non è stata modificata (insert ignore o insert ... on duplicate key update che risulta in modalità non operativa, executeBatch() restituisce 3), non è presente alcuna chiave.

3. Il ResultSet restituito da getGeneratedKeys avrà le voci per le righe correttamente inserite, come da (2). Non ci sarà una riga chiave generata per gli inserimenti non riusciti (dove il valore di conteggio degli aggiornamenti è Statement.EXECUTE_FAILED)

4. ?

5. Fare attenzione con rewriteBatchedStatements nella stringa di connessione JDBC. Se è impostato su true, qualsiasi errore comporterà il trattamento di ogni riga del "chunk" riscritto come se avesse avuto esito negativo. Un modo per gestire questo è iterare le righe fallite e riprovarle senza batch.

6. ?