Petites questions sur le sujet

Voilà que tout marche bien au niveau de mon projet.

De belles méthodes qui retournent List<ObjetPojo>

et dedans, au lieu d avoir du sql pourri, un beau truc du style:

Code:

---

1 2 3 4 5 6

Session session = HibernateUtil.currentSession(); session.beginTransaction(); List<RoleStation> results = session.createQuery("from RoleStation").list(); session.getTransaction().commit(); return results;

---

Je peux donc désormais me lancer dans le reste :)

Mais tout d'abord trouver comment envoyer SHUTDOWN au serveur, un simple: session.createSQLQuery("SHUTDOWN") suffit j'imagine?

avant le transaction.commit() bien sur

Merci encore pour votre aide;)

Oui, ça suffit

Par ailleurs, tu n'as pas besoin de transaction pour faire une liste ;)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Session session = null; List<...> result = null; try { session = HibernateUtil.currentSession(); result = session.createQuery(...).list(); } catch (Exception e) { ... } finally { HibernateUtil.closeSession(); // <------ Ne pas oublier de libérer }

---

Tout travail avec une base de données, doit se faire dans une transaction, même en lecture.
Autant prendre la bonne habitude de le faire.

Et pourquoi ???

Citation:

---

Envoyé par Bardack

session.createSQLQuery("SHUTDOWN") suffit j'imagine?

avant le transaction.commit() bien sur

Merci encore pour votre aide;)

---

Pour le shutdown il suffit d'envoyer l'ordre à la fermeture de ton appli, pendant tout le reste pas besoin.

Et pourquoi refuses tu catégoriquement de le faire en java alors que c'est carrément plus simple

Parce que j'ai testé avec : Server, sans comprendre, et que ca marche sans.

J'ai réussi en utilisant Server, mais ca n' a rien changé, toujours pas d écriture ...

Si tu as une idée, ou de quoi me montrer, n hésite dont pas.

Merci

Et cela marche tres bien de cette facon, sans etre pour autant "crade":

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public static void closeSession() throws HibernateException { Session s = (Session) session.get(); if ( s == null ) return ; s.beginTransaction(); s.createSQLQuery("SHUTDOWN"); s.getTransaction().commit(); session.set(null); s.close(); }

---

closeSession est apellé onClosing de ma JFrame. Donc pas de probleme.
Désormais ca ADD bien dans le fichier sur le disque.

/me 's happy :)

Parce que ça marche comme ça.

Imagine un service (qui ne fait que des lectures), dans lequel tu lis la même donnée par exemple, au début et à la fin de ton service.
Si entre les deux lectures, la donnée a été modifiée par un autre processus,
tu n'obientras plus le même résultat que lors de la première lecture, ce qui peut entrainer des erreurs.

Tu parles du niveau d'isolation je suppose... Mais là, tu ouvres une transaction , tu lis et tu fermes la transaction, alors dis-moi à quoi ça sert ???

à s'assurer que quelqu'un n'est pas en train d'écrire, de supprimer ou de mettre à jour une table au moment ou tu vas lire. Ce qui peut amener à l'apparition de données incohérentes

C'est plutôt une notion de verrouillage ça, la transaction est là pour garantir l'intégrité des données sur une ou plusieurs mise à jour / création / suppression d'enregistrements de une ou plusieurs tables...

http://forum.hibernate.org/viewtopic...098&highlight=

Un petit lien où intervient Anthony Patricio, auteur d'un bouquin sur Hibernate, et membre de l'équipe Hibernate.

Après avoir remarqué qu'on pouvait utiliser le polymorphisme,etc (de facon assez mystique a premiere vue), j' en viens a une autre question a laquelle je n'ai pas encore trouvé de réponse ...

Imaginons une table, Debit, et une table Interface.

Imaginons ensuite, une table Debit_Interface permettant d' établir la cohérence entre ces deux tables, a savoir: pour telle interface, on a accès a tel, tel et tel débit...

Cette derniere table serait donc constituée de trois colonnes:
id - interface - debit

interface et debit étant des foreign key vers les tables Debits et Interfaces.

J' en viens a la question, est il possible, par le biais de Hibernate, de faire quelque chose de la sorte:

Recuperer une List<InterfaceDebit> de la sorte:

Code:

---

1 2 3 4 5 6

Session session = HibernateUtil.currentSession(); session.beginTransaction(); List<InterfaceDebit> results = session.createQuery("from INTERFACE_DEBIT").list(); session.getTransaction().commit();

---

Et que cette classe persistente InterfaceDebit ne contienne non pas 3 INT (id-interface-debit- mais bien : un INT, un Debit, une Interface.

Debit et Interface etant deux autres classes persistentes.

Le but étant donc de pouvoir faire un truc du genre: (suite du premier code)

Code:

---

1 2	results.get(i).getInterface().getId();

---

Et donc de remplacer des FK d'une table par l'objet associé à l'ID faisant office de FK.
Merci de vos réponses

Oui, c'est d'ailleurs pour cela qu'hibernate est utile. Tu dois mapper les associations entre tes objets en indiquant de quel type elle est (one-to-many pour les collections, many-to-one pour les associations normales, many-to-many pour les associations bidirectionnelles multiples).

Pour les FK, c'est donc une many-to-one que tu dois utiliser.

Tout est expliqué ici :
http://www.hibernate.org/hib_docs/v3...l/mapping.html

Chapitre 5.1.10.

Citation:

---

Envoyé par fr1man

http://forum.hibernate.org/viewtopic...098&highlight=

Un petit lien où intervient Anthony Patricio, auteur d'un bouquin sur Hibernate, et membre de l'équipe Hibernate.

---

J'ai regardé ton lien, mais franchement, le gars est un peu comme toi, à la question de "Celine", il dit "il faut" mais il n'explique pas pourquoi.
Moi, j'aimerais (comme elle) savoir pourquoi il "faudrait" utiliser une transaction pour des lectures seules, alors que ça fonctionne très bien sans et qu'à mon sens, ce n'est pas fait pour ça...
Une transaction est un ensemble d'opérations de mise à jour (au sens large) db indissociables validées par un commit ou invalidées par un rollback (là au moins, j'espère qu'on est d'accord), mais la lecture, je ne vois pas... désolé...

Je me demande si on ne devrait pas faire une discussion à part pour ça, qu'en dis-tu ?

OK pour la nouvelle discussion.

Je que je trouve clair, c'est qu'il explique que tout accès à une base se fait dans une transaction, et que si tu n'en vois pas explicitement, c'est à cause
du mode autocommit.
Il cite l'exemple du repeatable read. C'est l'exemple que je t'ai donné.

Je sais pas pour vous, mais je trouve la doc de Hibernate assez mal faite ... je sens qu'on va me descendre en disant ca mais c'est mon avis ;)

...Feu !!! :zekill:

Non, pourquoi, tu as laquelle ?

Hibernate reference v2.1.8

Par contre le coup du many-to-one, je pensais pas que c'était SI simple a utiliser .... vraiment la folie ce truc :| :)