Qual è il modo migliore per leggere un UDT da un database con Java?

Question

pensavo di sapere tutto di UDT e JDBC fino a quando qualcuno su SO sottolineato alcuni dettagli della Javadoc di java.sql.SQLInput e java.sql.SQLData JavaDoc per me. L'essenza di quel pizzico era (da SQLInput):

Un flusso di input che contiene un flusso di valori che rappresentano un esempio di un tipo SQL strutturato o uno SQL tipo distinto. Questa interfaccia, utilizzato solo per la mappatura personalizzata, viene utilizzato da il driver dietro le quinte, e un programmatore mai direttamente invoca metodi SQLInput.

Questo è tutto il contrario di quello che sono abituato a fare (che è anche utilizzato e stabile nei sistemi produttivi, quando viene utilizzato con il driver JDBC Oracle): Implementare SQLData e fornire questa implementazione in una mappatura personalizzata per

ResultSet.getObject(int index, Map mapping)

Il driver JDBC sarà poi call-back sul mio tipo personalizzato utilizzando il

SQLData.readSQL(SQLInput stream, String typeName)

Metodo

. A implementare questo metodo e leggere ogni campo dal flusso SQLInput. Alla fine, getObject() restituirà un'istanza correttamente inizializzata della mia realizzazione SQLData contenente tutti i dati dal tipo definito dall'utente.

Per me, questo sembra il modo migliore per implementare tale mappatura personalizzata. Buone ragioni per andare in questo modo:

• posso utilizzare l'API standard, invece di utilizzare le classi specifiche del fornitore, come oracle.sql.STRUCT, ecc.
• I in grado di generare il codice sorgente dai miei UDT, con getter / setter appropriate e altre proprietà

Le mie domande :

• Che ne pensi di mio approccio, attuazione SQLData? E 'vitale, anche se il Javadoc afferma il contrario?
• Quali altri modi di leggere UDT di in Java Sapete di? Per esempio. che cosa fa primavera fare? che cosa fa Hibernate fare? Cosa fa JPA fare? Cosa fai?

Addendum :

supporto UDT e l'integrazione con le stored procedure è una delle caratteristiche principali di jOOQ . obiettivi jOOQ a nascondere le più complesse "fatti JDBC" dal codice del client, senza nascondere l'architettura database sottostante. Se avete domande simili come sopra, jOOQ potrebbe fornire una risposta a voi.

Answer 1

Il vantaggio della configurazione del driver in modo che lavora dietro le quinte è che il programmatore non ha bisogno di passare il tipo di mappa in ResultSet.getObject (...) e quindi ha un dettaglio meno di ricordare (la maggior parte del tempo ). Il conducente può anche essere configurato in fase di esecuzione utilizzando le proprietà per definire le mappature, in modo che il codice dell'applicazione può essere mantenuto indipendente dai dati del tipo SQL di mapping oggetto. Se l'applicazione potrebbe supportare diversi database diversi, questo consente diverse mappature da sostenere per ogni database.

Il vostro metodo è praticabile, la sua caratteristica principale è che il codice applicazione utilizza mapping dei tipi esplicite.

Nel dietro le quinte avvicinarsi il metodo ResultSet.getObject (int) utilizzerà i mapping dei tipi definiti sulla connessione piuttosto che quelli passati dal codice dell'applicazione in ResultSet.getObject (int index, mappa mappatura). In caso contrario, gli approcci sono gli stessi.

Altri approcci

Ho visto un altro approccio utilizzato con JBoss 4 sulla base di queste classi:

org.jboss.ejb.plugins.cmp.jdbc.JDBCParameterSetter 
org.jboss.ejb.plugins.cmp.jdbc.JDBCResultSetReader.AbstractResultSetReader

L'idea è la stessa, ma l'implementazione è non standard (probabilmente è precedente alla versione dello standard JDBC definisce SQLData / SQLInput).

Answer 2

Quali altri modi di leggere UDT di in Java Sapete di? Per esempio. che cosa fa primavera fare? che cosa fa Hibernate fare? Cosa fa JPA fare? Cosa fai?

Un esempio di come qualcosa di simile a questo può essere fatto in Hibernate / JPA è mostrato in questa risposta a un'altra domanda:

Java enumerazioni, JPA e Postgres enumerazioni - Come faccio a farli lavorare insieme

?

Answer 3

So cosa fa primavera: si scrive implementazioni di loro RowMapper interfaccia. Ho non utilizzato SQLData con la Primavera. Il tuo post era la prima volta che avessi mai sentito o pensato di tale interfaccia.