Newsgroup: it.comp.java
Titolo: tool per passare da statement SQL a classi Java

ciao,
Da un po' di tempo sto lavorando a un task ant open source che dato uno 
statement SQL tipo insert o select permette di generare classi java per 
eseguirli.
Per esempio dallo statement
insert into boosts(url,keyword,position,boost)
values('
http://gino
','aprikot',1,1)
crea la classe wrappers.BoostInsert che avrà un metodo run(String 
url,String keyword, int position, int boost) per eseguire la insert.
Funziona con statement arbitrari, anche con le select, nel qual caso 
genera un iteratore per scorrere le righe restituire, e un metodo getter 
per ogni colonna del result set.
Cosa ne pensate dell'idea? La trovate utile? c'è un tool analogo anche 
per le chiamate a stored procedures.
Questo è il sito del progetto 
http://spwrapper.sourceforge.net
Giovanni


Persitenza faidate? No Aplitour? Ahi ahi...
Mai sentito parlare di Hibernate?
Scherzi a parte, la tendenza dei programmatori OO e' rendere
persistenti gli oggetti i maniera
piu' sql-trasparente possibile. Il tuo sforzo, generare codice java
dal SQL va esattamente nellal direzione
opposta.

 eseguirli.
Tempo perso se il tuo intento e' fare qualcosa di utile per la comunita' 
Java.
Cerca ORM (Object-Relational Mapping) su Google e forse comprenderai il 
perche'.

 questo :)
IBatis non so perche' non lo conosco  (sebbene dubito altamente), ma 
Hibernate di sicuro non fa anche questo. 

 Hibernate di sicuro non fa anche questo. 
Beh non ti permette di inserire le istruzioni sql native ? a me sembra 
di si .... nn fa proprio la stessa cosa... ma lo usi per lo stesso scopo 
...no ?

"
pier...@alice.it
" <pi...@pippopippo.pp> ha scritto nel messaggio 
news:46cc9dfa$0$10626$4faf...@reader2.news.tin.it...


Anche JDBC allora...sai quante istruzioni SQL native di permette di 
inserire?
Meglio di entrambi quindi.
No, Hibernate fa ben altro: gestisce la persistenza degli oggetti del tuo 
dominio applicativo in maniera quasi totalmente trasparente.
Ora, questa e' la direzione della comunita' Java e anzi di qualsiasi altro 
framework ORM esistente (anche in altre piattaforme e linguaggi).

 
Si la mia scelta è molto contro corrente :)
Bhe a me è sempre capitato di lavorare in progetti in cui gli OR-mapper 
  non sono stati usati, vuoi perchè il gruppo di lavoro non era disposto 
a impararli, vuoi perchè il lavoro era vecchio e molte cose sono state 
ereditate. Adesso lavoro in un team molto db-centrico, e non java centrico.
Il mio scopo non è quindi partire dal disegno dell'oggetto per cui 
derivare le operazioni classiche di inserisci/rimuovi/modifica dei 
record, ma implementare velocemente qualche caso particolare e sempre 
adattarsi a uno schema db preesistente.
Per esempio: qualcuno ha fatto una stored procedure che fa ciò che mi 
serve, il mio tool ti genera un wrapper per invocarla comodamente.
Oppure ho una query un po' anomala tipo con aggregazioni per report, una 
volta che l'ho composta con pl/sql developer la copio e incollo in un 
file ant ed ho già la classe pronta per stampare i risultati in una 
pagina JSP.
Sono capitate anche a voi situazioni come queste? Riuscite ad 
affrontarle comodamente con Hibernate o iBatis? Ho passato molto tempo a 
fare in modo che il tool deducesse il tipo dei parametri dallo schema 
del db e dal risultato prodotto dalla query. Comunque non ho mai pensato 
a realizzare un intero sistema a botte di statement sql wrappato da java.
Ciao

pier...@alice.it
 ha scritto:

Bhe quello che SqlJaTor fa è permetterti di inserire un qualunque 
statement sql accettabile dal tuo database, quindi anche con costrutti 
speciali. Deduce dal tuo statement quelli che possono essere i parametri 
di ingresso ed il loro tipo (le costanti costanti che hai usato di 
esempio, poi il tipo se non ti va bene lo cambi come vuoi). Poi 
interroga il database per capire il tipo del risultato e in base a 
quello calcola il tipo dei parametri di uscita (idem se non ti va bene 
il mapping automatico lo puoi cambiare). Se è una select hai un 
iteratore per scorrere le righe...
Ho passato molto tempo sulla "deduzione" dei tipi per limitare la 
configurazione da scrivere a mano.
Giò

 
riccardo...@email.it
 ha scritto:

HIbernate ti permette anche di generare, a partire da una serie di
tabelle sul tuo DB,
le classi java che corrispondono a questi dati. Quindi anche se hai
unno schema DB pre-esistente
questo non rappresenta un problema. Come dicono gli stessi autori di
Hibernate pero', se la tua
e' un applicazione di piccole dimensioni non c'e' niente di eretico a
mantenere un approccio tabulare
con jdbc nudo. Francamente non capisco dove sia il vantaggio di
passare in ant da una query sql a una classe che la esegue, visto che
l'esecuzione di una query in Java prende tre righe. La parte rognosa
per un prog java non e' tanto eseguire la query, ma trasportare i
risultati della query dal formato tabulare al suo
modello di oggetti. Oppure l'operazione inversa, raccogliere i dati
appartaneneti  apiu ogggetti e spararli su una o piu tabelle
ralazionali.  E' proprio questo che fa Hibernate,e se la tua
applicazione non ha un modello ad oggetti completo (perche' magari e'
di iccole dimensioni e non ne vale la pena) allora non vale molto la
pena di complicarsi la vita con vari tools. certo il tuo puo' essere
un buon esercizio per conoscere meglio ant! ma mi ricorda vagamante il
complesso del martello: "quando si ha un martello in mano (leggi
quando si ha capito come creare un task ant), tutto quello che c'e'
attorno sembra un chiodo".

 
L'idea del file ant mi è venuta per i continui cambi di 
parametro/aggiunta di colonne alle tabelle. Rifai girare lo script e si 
aggiornano le classi in funzione dei cambiamenti allo schema. Se devi 
solo leggere i dati vengono automaticamente aggiunti dei getter, ma se 
il tipo cambia o servono altri input la signature dei metodi cambia e 
ricompilando trovi subito i punti da modificare.