Newsgroup: it.comp.java
Titolo: Hibernate e tabelle di decodifica

Ciao a tutti.
Sto studiando hibernate, e ho un dubbio sulla gestione delle tabelle
di decodifica, ovvero le tabelle che semplicemente hanno una
descrizione di un certo valore.
Esempio:
Utente
------------------
|id              |
------------------
|login          |
|pwd           |             Stati
|...              |             ------------------
|fk_id_stato |-------------| id             |
                               ------------------
                               |descrizione|
Ovvero una tabella Utente che fra i suoi campi prevede uno stato che
la cui descrizione è inserita in una tabella a parte fatta
semplicemente con chiave-descrizione.
Studiando il manuale ho visto che potrei gestire il tutto creando due
Entity e poi unirli in una relazione Uno a Molti.
@Entity
@Table(name = "User")
public class User implements Serializable{
	Long id;
	String login;
	String pwd;

Scusate, partito l'nvio per sbaglio.






         Stato stato;
         ....
        @ManyToOne
        public Stato getStato(){
           return stato;
        }
....
}
 @Entity
 @Table(name = "Stato")
 public class Stato implements Serializable{
 Long id;
 String desc;
 List<User> users;
...
OneToMany(mappedBy="stato")
public List<User> getUsers(){
  return users;
}
}
Non l'ho provato ma credo che funzioni.
La domanda è: ci sono delle scorciatoie?
Magari una qualche annotation che velocizza il tutto...
Sono molto all'inizio dello studio, quindi potrei anche essermi perso
qualcosa di banale.
Ciao, grazie
Alessandro

 Magari una qualche annotation che velocizza il tutto...
No, meno di così non credo sia possibile.
Al limite, se non ti interessa la relazione inversa, che, secondo me in
una tabella di decodifica è inutile, e complica inutilmente le cose, in
Stato potresti risparmiarti users e relativi setter, getter e annotazioni.
In ogni caso la ricerca di tutti gli User in un certo Stato lo faresti
tramite l'entità User, con una query del tipo:
from User u where 
u.stato.id
=?
Poi...se non ci fosse realmente la necessità di una tabella di
decodifica (cioè, se gli stati e le relative descrizione fossero fissi e 
in numero non troppo grande), forse una scelta migliore sarebbe quella 
di usare un Enumeration. Qualcosa tipo:
public enum Stato {
	ACTIVE, DISABLED, DELETED
}
...e in User:
private Stato stato;
...
@Enumerated(EnumType.STRING)
public Stato getStato()
   return stato;
}
Ciao
   Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org

 JUG Padova          
http://www.parancoe.org.
..have a look at it!
www.jugpadova.it
 
http://www.jugevents.org
Provero' l'enum, mi sembra adatto alle mie esigenze.
Grazie.
Ma per scrivere gli entity esiste qualche tool comodo?
Io uso eclipse con il plugin di jboss, ma gli entity li scrivo
completamente a mano (tranne i getter e setter :-) )
In un altro post di qualche giorno fa mi consigliavano di non partire
dal db, ma direttamente dagli entity e allora mi chiedevo....
Grazie
Ciao
Alessandro

 dal db, ma direttamente dagli entity e allora mi chiedevo....
Ciao,
io li scrivo a mano. Se puoi avere massima libertà sul DB, secondo me il 
consiglio che ti hanno dato è ottimo (cioè generare il DB a partire dai 
tuoi entity).
In realtà li scrivo partendo da una classe base che implementa id, 
version e le implementazioni di base di equals e hashcode (e anche 
toString...ma questo è solo per comodità di logging), quindi il resto di 
solito è piuttosto semplice.
Poi i metodi per le operazioni sugli entity e per le query li scrivo 
molto facilmente in dei DAO generici.
...e scrivendo pochi semplici test sul DB per verificare la correttezza 
del modello e che tutto stia funzionando, il tutto viene molto naturale.
Se ti può interessare, tutto questo è racchiuso in Parancoe, un 
meta-framework che sto scrivendo assieme ad altri membri del JUG Padova.
Per avere un'idea della parte di persistenza puoi dare un'occhiata al 
seguente tutorial:
http://www.parancoe.org/articles/2006/06/09/parancoe-persistence-tutorial/
e magari anche questo:
http://www.parancoe.org/articles/2007/08/28/how-to-add-finder-methods-to-parancoe-daos/
...scrivere i test sul DB poi è la parte divertente. Ad esempio, questo 
è quanto di più semplice si possa pensare:
public class EventResourceDaoTest extends JugEventsBaseTest {
     private EventResourceDao eventResourceDao;
     public EventResourceDaoTest() {
         Daos daos = (Daos) ctx.getBean("daos");
         eventResourceDao = daos.getEventResourceDao();
     }
     public void testFindAll() {
         List<EventResource> resources = eventResourceDao.findAll();
         assertSize(7, resources);
     }
}
...ma fa tutto...cancellazione e ripopolamento del DB con dati di test 
prima dell'esecuzione di ogni test, anche con legami con altre 
entity...pieno accesso alle funzionalità dei DAO...ecc.ecc.
...scusa la prolissità.
Ciao
   Lucio
-- 
Lucio Benfante


 La domanda è: ci sono delle scorciatoie?
si.
che ti puoi risparmiare la relazione onetomany sulla entità degli stati, 
che è sicuramente inutile se non ti interessa avere come proprietà degli 
stati la lista degli utenti che vi appartengono.
-- 
 Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com
http://www.flickr.com/photos/marko_po/