[JAVA] ORM leggeri, avete provato questi? [Archivio]

banryu79

30-10-2009, 16:41

Salve,
mi chiedevo se qualcuno degli utenti del forum che programma in Java avesse per caso usato uno di questi ORM, e se sì se può cortesemente postare le sue impressioni, perchè sto cercando un ORM che abbia le caratteristiche di essere il più semplice e meno "pervasivo" possibile, a configurazione-zero o quasi, da utilizzare solo per applicazioni desktop stand-alone di piccole e medie dimensioni.
Naturalmente l'affidabilità è un requisito.

Gli ORM in questione sono i seguenti:
SimpleORM (http://www.simpleorm.org/sorm/whitepaper.html)
Ammentos (http://www.ammentos.org/)
Persist (http://code.google.com/p/persist/)
pBeans (http://pbeans.sourceforge.net/)

Ben vengano consigli di altri ORM non elencati che rientrano nella casistica descritta sopra.
Grazie in anticipo per qualsiasi contributo :)

wizard1993

31-10-2009, 12:24

avevo scoperto l'ultimo, ma non ero riuscito a trovare la documentazione e quindi non ne avevo fatto di nulla.

io comunque, a dir la verità nel mio ultimo progetto ho usato un sistema un po' in "diverso":
in java mi sono appoggiato alla libreria xstream (che fa lo stesso lavoro delle XMLDecoder/XMLEncoder, ma più veloce) per serializzare un oggetto, salvando poi l'xml corrispondente in un database (ho usato il postgres), usando come chiave quella dell'oggetto stesso,tutto "nascosto" in una classe che implementa Map.
Le prestazioni sono più che soddisfacenti se la mole di dati non è eccessiva, coprendo con estrema semplicità per il programmatore il campo che questi orm si contendono : applicazioni semplici, con entità semplici magari senza la necessità (e soprattuto il tempo uomo) per fare 2500 file di configurazioni.
in questo campo secondo me sono interessanti anche le BerkeleyDB della Oracle

shinya

31-10-2009, 12:51

Degli ORM che hai indicato tu devo confessare di non conoscerne nemmeno uno.
Dato che anch'io ho un'antipatia profonda per gli ORM 'standard', avevo trovato un'isola felice in ActiveObjects:

https://activeobjects.dev.java.net/

Configurazione zero, semplice, basilare.

Detto questo, probabilmente se dovessi cominciare un progetto da zero adesso non credo userei un db relazionale, ma qualcosa document-oriented tipo tokyo cabinet o simili...

wizard1993

31-10-2009, 17:19

ma qualcosa document-oriented tipo tokyo cabinet o simili...

gli ho dato un occhiata veloce, mi ricorda vagamente cloud db... sto sparando qualche boiata?

shinya

02-11-2009, 08:26

gli ho dato un occhiata veloce, mi ricorda vagamente cloud db... sto sparando qualche boiata?
Non conosco cloud db, ma dopo una veloce occhiata sull'interwebz direi che no, non c'entrano niente l'uno con l'altro.
Tokyo Cabinet sostanzialmente è una grossa hashtable... che poi non è cosi, ma fai prima a leggere la documentazione.

banryu79

02-11-2009, 09:50

Vi ringrazio per i vostri interventi.

io comunque, a dir la verità nel mio ultimo progetto ho usato un sistema un po' in "diverso":
in java mi sono appoggiato alla libreria xstream (che fa lo stesso lavoro delle XMLDecoder/XMLEncoder, ma più veloce) per serializzare un oggetto, salvando poi l'xml corrispondente in un database (ho usato il postgres), usando come chiave quella dell'oggetto stesso,tutto "nascosto" in una classe che implementa Map.

Tecnica interessante, ma per il momento vorrei vedere se riesco a trovare un ORM semplicissimo che soddisfi le mie neccessità, in un "unico pacchetto".

in questo campo secondo me sono interessanti anche le BerkeleyDB della Oracle.

Non le conoscevo, ho dato un'occhiata sul sito e ho visto la formula delle licenze: se mai dovessi ridistribuire (e potrebbe capitarmi), essendo le BerkleyDB open source dovrei acquistare la licenza commerciale.
Il che significa che dovrei prima informarmi meglio e vedere quanto costa e cosa comporta, e se il gioco vale la candela.
Questo a prescindere dalla qualità del prodotto (che comunque mi sembra ottima).

...avevo trovato un'isola felice in ActiveObjects:

Interessante, lo valuto.
Peccato che non sia ancora abbastanza maturo, però vale la pena approfondire.

Detto questo, probabilmente se dovessi cominciare un progetto da zero adesso non credo userei un db relazionale, ma qualcosa document-oriented tipo tokyo cabinet o simili...

Interessante anche questo, solo che gira solo su piattaforme UNIX-like, e me serve una soluzione che giri anche su ambienti Windows.

Vi ringrazio ancora per i vostri interventi.

elleby

02-11-2009, 10:06

Ma Hibernate non ti piace?

banryu79

02-11-2009, 10:43

Ma Hibernate non ti piace?
Non è una questione di piacere o non piacere.
I motivi e il senso della mia richiesta sono esplicitati nel mio primo post.

ally

02-11-2009, 12:52

RaouL_BennetH

02-11-2009, 13:12

...scusate l'intromissione...ma ogni tabella deve implementare obbligatoriamente una colonna "id"?...

...ciao Andrea...

Ciao :)

Non so per gli altri ORM, ma Hibernate/Nhibernate ti permettono di crearti una tua ID laddove non ci sia nella tabella corrispondente.

L'unica cosa che dovrai fare oltre che definirla nell'entità che rappresenti, assegnarle come generator il valore 'assigned':

<id name="NomeId" column="columnId" type="Int32" unsaved value=0>
<generator class="assigned"</generator>
</id>

banryu79

02-11-2009, 13:16

...scusate l'intromissione...ma ogni tabella deve implementare obbligatoriamente una colonna "id"?...

Non lo so, al momento sono impegnato a testare Ammentos con una semplice applicazione di prova creata appositamente: voglio testare a sufficienza quelli che ho già citato più ActiveObject perchè, al di là della semplicità dei meccanismi d'uso o delle eventuali costrizioni che impongono voglio rendermi conto di quanto trasparenti sono al problema della mappatura dal paradigma OO delle entità Java al dominio delle tabelle relazionali del database e come questo aspetto mi possa condizionare nel design dell'applicativo.

Ad esempio, da questo punto di vista, per quel che ho visto fin'ora, Ammentos non mi sta soddisfando: è di semplicissimo utilizzo, ma mi costringe a pensare e disegnare in dettaglio prima le tabelle del db, per poi creare le entità Java.
Io invece vorrei fare proprio l'opposto: progettare il mio modello delle entità in termini OO e poi lasciare il più possibile all'ORM l'incombenza di realizzare una mappatura coerente in termini di tabelle di database relazionale.

Comunque, leggendo qua, di primo acchito direi di che non serve, e che si crea da solo la colonna per la chiave primaria:
https://activeobjects.dev.java.net/basic-concepts.html

ally

02-11-2009, 13:18

Ciao :)

Non so per gli altri ORM, ma Hibernate/Nhibernate ti permettono di crearti una tua ID laddove non ci sia nella tabella corrispondente.

L'unica cosa che dovrai fare oltre che definirla nell'entità che rappresenti, assegnarle come generator il valore 'assigned':

<id name="NomeId" column="columnId" type="Int32" unsaved value=0>
<generator class="assigned"</generator>
</id>

...stavo parlando di ActiveObjects...che non necessità di un file .xml...ricava la struttura tabelle direttamente da un interfaccia Java ma sembra vincolato alla presenza di una colonna "ID"...spero di sbagliarmi perchè tale richiesta è assolutamente limitante...

...ciao Andrea...

banryu79

02-11-2009, 13:24

Ciao :)
Non so per gli altri ORM, ma Hibernate/Nhibernate...

Ciao Raoul,
il problema non è se esite un qualsiasi framework ORM che faccia questo & quello: Hibernate poi, in particolare, è famosissimo e penso che quasi tutti lo conoscano.

Il problema che mi ero posto era un'altro: devo scrivere una semplice applicazione di questo tipo:
- stand alone desktop application
- di piccole, al massimo medie, dimensioni
- sto programmando OO (almeno: ci provo :Prrr:) in Java

Esiste un ORM (libreria o framework) che soddisfi questi vincoli:
- semplice da integrare con il codice
- a configurazione-zero (no tonnellate di XML per definire le mappature)
- manipola in modo trasparente al programmatore lo schema del db basandosi interamente sulle entità definite nel codice
- mi permette quindi di progettare le entità in modo OO, le tabelle del db a me non interessano (che le definisca l'ORM)

Capito che cerco? Perchè è già passato qualcun'altro prima a chiedermi perchè non mi piacesse Hibernate :rolleyes:

RaouL_BennetH

02-11-2009, 13:30

Ciao Raoul,
il problema non è se esite un qualsiasi framework ORM che faccia questo & quello: Hibernate poi, in particolare, è famosissimo e penso che quasi tutti lo conoscano.

Il problema che mi ero posto era un'altro: devo scrivere una semplice applicazione di questo tipo:
- stand alone desktop application
- di piccole, al massimo medie, dimensioni
- sto programmando OO (almeno: ci provo :Prrr:) in Java

Esiste un ORM (libreria o framework) che soddisfi questi vincoli:
- semplice da integrare con il codice
- a configurazione-zero (no tonnellate di XML per definire le mappature)
- manipola in modo trasparente al programmatore lo schema del db basandosi interamente sulle entità definite nel codice
- mi permette quindi di progettare le entità in modo OO, le tabelle del db a me non interessano (che le definisca l'ORM)

Capito che cerco? Perchè è già passato qualcun'altro prima a chiedermi perchè non mi piacesse Hibernate :rolleyes:

Scusami Banryu79, avevo solo risposto ad:

Originariamente inviato da Ally
...scusate l'intromissione...ma ogni tabella deve implementare obbligatoriamente una colonna "id"?...

...ciao Andrea...

:ops:

ally

02-11-2009, 13:33

Comunque, leggendo qua, di primo acchito direi di che non serve, e che si crea da solo la colonna per la chiave primaria:
https://activeobjects.dev.java.net/basic-concepts.html

...forse mi sto perdendo qualcosa...ma il comando migrate aggiorna la tabella secondo le modifiche apportate alla interfaccia...ma quando mostra lo script che migrate crea ci ritroviamo la fantomatica colonna id assolutamente assente tra i metodi esposti dall'interfaccia...

CREATE TABLE person (
id INTEGER AUTO_INCREMENT NOT NULL,
firstName VARCHAR(255),
lastName VARCHAR(255),
PRIMARY KEY (id)
);

public interface Person extends Entity {
public String getFirstName();
public void setFirstName(String name);

public String getLastName();
public void setLastName(String name);
}

...forse è meglio se apro un thread specifico?...

...ciao Andrea...

banryu79

02-11-2009, 13:34

Scusami Banryu79...

Ma figurati, sei sempre il benvenuto :)

Però ho colto al balzo l'occasione per ripetere i requisiti di quel che cerco, così chi incappa nel thread non rischia di capire "pan per polenta" e confondersi.

banryu79

02-11-2009, 13:40

...forse mi sto perdendo qualcosa...ma il comando migrate aggiorna la tabella secondo le modifiche apportate alla interfaccia...ma quando mostra lo script che migrate crea ci ritroviamo la fantomatica colonna id assolutamente assente tra i metodi esposti dall'interfaccia...

Sì, quello l'ho visto e ho pensato che sia lui dietro le quinte a inserire nello script il codice neccessario per creare/gestire il campo della primary key.

Evidentemente quando esegui un save() della tua entità, se è una nuova nel database viene generato un nuovo record e un nuovo valore per la primary key, se invece stai facendo il save() di un'entità recuperata già presente, farà solo l'UPDATE.

Non so dirti altro: devo prima testarlo.
Ma se hai dubbi postrsti provarlo direttamente e poi farci sapere ;)

...forse è meglio se apro un thread specifico?...

...ciao Andrea...
Se sei veramente intenzionato a metterti là a provarlo, fai pure.
In tal caso, man mano che provo gli ORM, posso postare pure io le mie impressioni; potrebbe venirne fuori un thread utile.

ally

02-11-2009, 13:54

Sì, quello l'ho visto e ho pensato che sia lui dietro le quinte a inserire nello script il codice neccessario per creare/gestire il campo della primary key.

Evidentemente quando esegui un save() della tua entità, se è una nuova nel database viene generato un nuovo record e un nuovo valore per la primary key, se invece stai facendo il save() di un'entità recuperata già presente, farà solo l'UPDATE.

...ho creato una classe di test e ho puntato ad una tabella priva di colonna "ID"...il risultato è stata una bella eccezione :

java.sql.SQLException: Unknown column 'id' in 'field list'
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2928)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1571)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1666)
at com.mysql.jdbc.Connection.execSQL(Connection.java:2994)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:936)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1030)
at net.java.ao.EntityManager.find(EntityManager.java:682)
at net.java.ao.EntityManager.find(EntityManager.java:607)
at net.java.ao.EntityManager.find(EntityManager.java:555)
at it.ally.activeobject.ActiveObjectTest.main(ActiveObjectTest.java:27)

...aggiungendo la nuova primarykey nel db e non toccando il codice java il tutto funge senza problemi...

...ciao Andrea...

wizard1993

02-11-2009, 13:59

In tal caso, man mano che provo gli ORM, posso postare pure io le mie impressioni; potrebbe venirne fuori un thread utile.

sarebbe molto molto interessante visto e considerato che mi trovo molto spesso nella condizione di realizzare piccoli/piccolissimi gestionali, in cui ogni un orm alla topLink sono veramente troppo

banryu79

02-11-2009, 14:58

sarebbe molto molto interessante visto e considerato che mi trovo molto spesso nella condizione di realizzare piccoli/piccolissimi gestionali, in cui ogni un orm alla topLink sono veramente troppo
Bhe, a dire il vero, nell'elenco inziale non ho incluso una soluzione che ho incontrato, molto esotica e che potrebbe essere molto interessante, per progetti piccolissimi: space4j (https://space4j.dev.java.net/)

Attenzione: non è un ORM, ma un "Prevalent system": in pratica tiene in memoria gli oggetti business e tutte le transazioni vengono loggate per tenere aggiornato lo stato del sistema ai successivi riavvii.

Io non l'ho considerato perchè il progetto hostato su dev.java.net non viene più aggiornato da 21 mesi...

Però l'autore di space4j ha preso l'idea da Prevayler (http://www.prevayler.org/wiki/)
Prova a darci un occhio: promette libertà completa da SQL, tabelle e database engine, tutto in una botta (lo valuterò anche io) :D

wizard1993

02-11-2009, 17:51

sono molto interessanti, io invece ho trovato xbird, che sembra esattamente quello che mi serve
http://code.google.com/p/xbird/

Mesh89

02-11-2009, 18:28

Esiste un ORM (libreria o framework) che soddisfi questi vincoli:
- semplice da integrare con il codice
- a configurazione-zero (no tonnellate di XML per definire le mappature)
- manipola in modo trasparente al programmatore lo schema del db basandosi interamente sulle entità definite nel codice
- mi permette quindi di progettare le entità in modo OO, le tabelle del db a me non interessano (che le definisca l'ORM)

Capito che cerco? Perchè è già passato qualcun'altro prima a chiedermi perchè non mi piacesse Hibernate :rolleyes:

Scusa, non fucilarmi, ma:

- Hibernate.
- Hibernate annotations + Hibernate tools, così hai bisogno solo di dare al wizard qualche parametro ovvio, tipo l'URI del db, e qualche annotation a classe. Nessun mapping xml.
- Hibernate di crea da solo le tabelle e quant'altro, mettendo UN parametro di configurazione.
- E' esattamente quello a cui serve.

Più, ma mi sembra superfluo aggiungerlo, uno strumento potentissimo, probabilmente molto più di qualsiasi alternativa, stabile e rodato, usato in ambienti di produzione molto seri, documentato e con una buona community alle spalle.

Mi unisco anch'io a quelli che non capiscono perchè non ti piaccia Hibernate, scusa se son tonto :(

banryu79

03-11-2009, 08:47

Quoto queste due espressioni, perchè mi hanno colpito:
Scusa, non fucilarmi, ma:
...
Mi unisco anch'io a quelli che non capiscono perchè non ti piaccia Hibernate, scusa se son tonto :(
Qua nessuno fucila nessuno :)
Non vedo il motivo di scusarsi, ne perchè dovrei mai "fucilarti"...
Accetto qualsiasi intervento purchè sia argomentato.
Se ti riferisci al post del tizio che mi ha chiesto perchè non mi piacesse Hibernate, non so se hai notato che non ha aggiunto altro. Nessuna informazione utile, zero.
Post del genere non mi sono di aiuto.

Il tuo post invece porta delle ragioni a sostegno.
La mia situazione è che per la parte relativa alla persistenza dei dati su db relazionali in passato non me ne sono mai occupato in prima persona, cosa di cui ora mi tocca, ma ho solo avuto a che fare con il DAO scritto da terzi.

Ora neccessito di colmare questo gap, in parte per motivi professionali e in parte per approfondimento personale.
Parto quindi da una posizione di ignoranza e mancanza di esperienza diretta.
Prima di buttarmi a testa bassa su Hibernate (del quale, tanto per chiarire, non metto in dubbio la qualità e stabilità) mi stavo chiedendo se non "fosse troppo" per le mie neccessità (applicazioni piccole) ed esistesse qualcosa di ancora più rapido e leggero, anche dal punto di vista del deployment della applicazione.

Ammetto di ignorare quanto possa incidere Hibernate da questo punto di vista, ma se tu lo usi, mi faresti una gran cortesia nel colmare questa mia ignoranza.

wizard1993

03-11-2009, 14:20

Mi unisco anch'io a quelli che non capiscono perchè non ti piaccia Hibernate, scusa se son tonto :(

in una sola parola: è troppo, almeno per me: lasciando da parte che non posso restare vincolato all'ambiente di sviluppo con i plugin, hibernate diventa paurosamente comodo quando devi fare "molto" ossia devi gestine 80 oggetti in 150 tabelle, transizioni di tutti i tipi e colori ecc, in caso contrario perde la sua necessità di esistere, ossia le grosse piattaforme.
io ho avuto esperienze solo con toplink (alla fine sono la stessa identica cosa) e mi sono accorto che se devo usare un mastodonte (che per via della sua enorme infrastruttura non è nemmeno troppo "snello") quando per le mie esigenze mi basta di fatto serializzare una treemap con gli oggetti che ho dentro mi faccio solo del male.
questo almeno è il mio pensiero

Mesh89

03-11-2009, 15:51

Ammetto di essere abbastanza ignorante, perchè avendo usato solo Hibernate, non so in che modo possano essere più semplici altri framework di questo tipo.
Posso comunque dirti che Hibernate è stata la mia prima esperienza in questo senso, e mi è sempre parso uno strumento amichevole. E' potente, e se vai in profondità inizia a diventare davvero complicato, ma se resti in superficie piuttosto semplice.

Ti porto l'esempio di una piccola applicazione web che ho iniziato a sviluppare per sfizio, che riflette più o meno la tua situazione: memorizzare dati preoccupandosi il meno possibile di ciò che è annesso.

Hibernate in questo caso è stato:
- Qualche jar da includere (e vorrei vedere).
- Un file di configurazione, che contiene parametri che oserei definire necessari (URI del db, username e password, robe simili). Hibernate Tools, un plugin di Eclipse, te le genera con un wizard, ma è l'unica cosa di Hibernate legata a Eclipse (di cui si può benissimo fare cmq a meno).
- Una classe con un metodo statico che mi restituisce una sessione all'occorrenza.
- In ogni classe che vuoi rendere una entity hibernate, metti un @Entity sopra la sua dichiarazione. Su un parametro, che farà da PK, @Id, ed eventualmente la strategia di generazione (l'autoincrementale è terribilmente comodo) se non vuoi gestire a mano gli le PK. Più un'annotation (che può essere ManyToOne, ManyToMany, OneToMany, etc) su ogni campo della classe che identifica una relazione con un'altra tabella.

Sinceramente non so quanto più semplice di così potrebbe diventare la cosa, ma se si può, ben venga!

wizard1993

03-11-2009, 17:44

allora, intanto devo dirti che i miei requisiti sono sensibilmente diversi da quelli da quelli di banryu: lui si riferisce a ambienti in cui comunque ci sia dietro un database relazionale, io invece no.
Quello che voglio scrollarmi di dosso è tanto il tempo uomo per la configurazione, quanto (e soprattutto) togliermi di dosso l'infrastruttura di un database relazionale esterno con cui è necessario dialogare in un altro linguaggio (l'sql).Sinceramente mi risulta indifferente che lo faccia una libreria o lo faccia io a mano ed è per questo che mi risultano molto interessanti librerie come tokio cabinet e soprattutto le berkeydb.
Hibernate, invece, ha comunque la necessità di appoggiarsi ad un database esterno, che sia lo snello javadb o il mastodontico oracle è in questo caso indifferente.
Proprio sul sito delle berkley(che è della oracle) c'è (o meglio c'era, ora non lo trovo) un interessante documento su come sulle piccole applicazioni fosse vantaggioso l'uso di database puramente embedded, non a metà come hibernate o toplink(quest'ultimo citato come paragone, da notare che è prodotto dalla oracle) che altro non sono che un layer di traduzione per qualcosa che gli sta sotto.
In mancanza di ciò, visto che ancora non l'ho trovato, cerco qualcosa di più snello possibile

EDIT: mi sono accorto che ho fatto un monologo