Salut,
Lors de la réunion dev, nous avons évoqué le problème de la version
d'Hibernate dans ToPIA.
Grosso modo, il s'agit de ce ticket [1] qui soulève un soucis, à savoir :
comment bénéficier des derniers versions d'Hibernate alors qu'elles ne
sont plus sur central.
À cette occasion, j'ai donc dit que cela me parraissait bizarre en
prenant l'exemple de spring-orm (version 3.0.x) présent sur central, et
compatible avec Hibernate 3.6.x.
Or en regardant dans le pom de spring-orm, il s'avère qu'il n'a de
dépendances que sur hibernate-annotations, hibernate-core et
hibernate-entitymanager dans ses versions 3.3.1 et 3.4.0, le tout en
<optional>true</optional>.
Si je n'm'absue, cela signifie que spring-orm ne tire pas les dernières
versions de Hibernate et compte sur la compatibilité ascendante
d'Hibernate pour continuer de fonctionner lorsque l'utilisateur inclut
lui même hibernate-* en version 3.6.x ?
Malheureusement, je ne pense pas que nous puissions faire de même car un
des buts de ToPIA est de ""masquer"" (autant que possible) la
persistence, et donc Hibernate. Dur dans ces cas-là de demander à
l'utilisateur de ToPIA d'inclure lui-même Hibernate...
A l'heure actuelle, nous sommes donc bloqués à la version 3.3.2.GA
d'Hibernate qui date du 21/08/2009. Nous n'avons donc (arrêtez moi si je
me trompe) bénéficié d'aucune amélioration/fonctionnalité depuis cette
date, et pour un projet comme ToPIA, je pense que ce n'est pas concevable...
Visiblement, nous avons 4 choix :
- passer la dépendance en optional façon spring-orm et demander à
l'utilisateur de tirer lui-même hibernate-3.6.x. Mais est-ce faisable ?
- sortir ToPIA de central :(
- ne sortir qu'une partie de ToPIA de central (comme dans le dernier
commentaire ici [2]). Mais je ne pense pas que ce soit faisable pour ToPIA.
- attendre (ad vitam eternam?) que Hibernate soit (re)synchronisé sur
central. Mais le statut et les commentaires du ticket en [2] me fait
dire que ce ne sera jamais fait.
Que voyez-vous d'autre ?
Que fait-on ?
Arnaud.
[1] http://www.nuiton.org/issues/show/476
[2] http://opensource.atlassian.com/projects/hibernate/browse/HHH-5101
Salut,
Contexte
--------
Il est actuellement possible de rajouter des méthodes métiers aux DAO
mais je trouve la manière de faire un peu trop lourde et j'aimerai bien
la simplifier.
Comment on fait actuellement
----------------------------
- Il faut écrire une interface (SpecieDAO)
- Y ajouter un stéréotype dao
- Ajouter une dépendance nommé dao vers l'entité de rattachement
Ce que j'imagine
----------------
Dans la solution actuelle, je trouve ça bien redondant d'écrire deux
fois dao (et surtout le vois pas trop à quoi ça sert...).
Je verrais bien une simplification en supprimant tout simplement le
stéréotype dao qui n'apporte pas grand chose.
De plus la liaison dans le sens du dao vers l'entité je trouve ça assez
dérangeant... On ajoute bien une extension à l'entité (à son DAO) je
préfèrerais vraiment une lien dans l'autre sens.
A noter que la deuxième demande nécessite de repasser sur les modèle
utilisant ce mécanisme :( mais serait quand même beaucoup plus propre à
mon gout car il il irait dans le même sens que d'autres choses faites
déjà (pour les constantes en l'occurrence).
A vos avis, remarques :)
--
Tony Chemit
--------------------
tél: +33 (0) 2 40 50 29 28
email: chemit(a)codelutin.com
http://www.codelutin.com
Salut !
J'ai créé un troll, heu... ticket là dessus [1], mais je pense que le
débat mérite d'être fait en français sur cette liste avant de polluer le
ticket.
Il y a des choses à creuser mais je trouve que cela simplifierait
la lecture des applications Topia au niveau des TopiaContext et de leur
traitement.
Un aperçu de ce que cela pourrait donner :
public class MyService {
@TopiaDAOFactory
protected MyDAOFactory daoFactory;
public MyService(Properties properties) {
daoFactory = new MyDAOFactory(properties);
}
@TopiaTransaction
public Book saveBook(Book book) {
BookDAO bookDAO = daoFactory.getBookDAO();
bookDAO.update(book);
return book;
}
}
A vos avis ;)
[1] http://nuiton.org/issues/show/1467
Hello,
Je pense avoir corrigé cette anomalie :
http://nuiton.org/issues/show/561
En fait l'utilisation du ConnectionProvider
fournit par hibernate
(org.hibernate.connection.DriverManagerConnectionProvider) pose un
problème de gestion des connections fermées [0].
En effet on met dans le pool lorsqu'on ferme la connection (au niveau
de l'api d'hibernate). En fait la connection n'est pas fermée (au
niveau JDBC).
Le problème c'est que l'on ne vérifie pas si cette connection n'a pas
été fermée au niveau JDBC et donc on peut mettre dans le pool une
connection fermée et donc non utilisable ensuite.
J'ai écrit une nouvelle version de la classe de base
(org.nuiton.topia.framework.TopiaConnectionProvider).
(j'ai pas pu étendre celle d'hibernate vu que tout est en private sans
aucun accesseur (bouh!)) donc un petit fork nécessaire.
Pour les curieux mon provider est ici : [1]
Pour ceux qui ont eu le problème il faudrait essayer ce provider,
et bien s'assurer qu'hibernate l'utilise (je pense à jboss qui pourrait
faire des siennes et utiliser une DataSource ?).
A vos réactions ;) et bon tests.
[0]
http://www.docjar.com/docs/api/org/hibernate/connection/DriverManagerConnec…
[1]
http://svn.nuiton.org/svn/topia/trunk/topia-persistence/src/main/java/org/n…
--
Tony Chemit
--------------------
tél: +33 (0) 2 40 50 29 28
email: chemit(a)codelutin.com
http://www.codelutin.com
