Probleme : dao.commitTransaction()
Salut à tous, Je me retrouve avec un petit souci sur le commitTransaction des DAO. En fait il ne fonctionne pas du tout, il ne se passe rien en Base ! J'ai regardé le code et j'ai constaté dans TopiaDAOAbstract : /** * Par defaut ne fait rien */ public void commitTransaction() throws TopiaException { } /** * Par defaut ne fait rien */ public void rollbackTransaction() throws TopiaException { } Les DAO générés n'étendent pas TopiaDAOAbstract mais TopiaDAODelegator qui lui implémente ces deux méthodes : public void commitTransaction() throws TopiaException { getParentDAO().commitTransaction(); } public void rollbackTransaction() throws TopiaException { getParentDAO().rollbackTransaction(); } Il fait appel au parentDAO pour faire le commitTransaction(). Le parentDAO est initialisé au moment de la récupération du DAO, cad via la methode getMonDAO du ModelHelperDAO généré par ToPIA. Cette méthode appel le getDAO de TopiaContextImpl qui cherche le bon DAO et lui set comment parent un TopiaDAOHibernate par défaut. TopiaDAOHibernate extends TopiaDAOAbstract et n'implémente pas les deux méthodes concernés ! Donc le commitTransaction() fait au départ ne fait rien. Une autre classe extends TopiaDAOAbstract, il s'agit de TopiaDAOFlatfile qui elle, implémente les deux méthodes (vides comme dans le Abstract). Donc normalement rien n'empêcherait de remplir ces deux méthodes directement dans TopiaDAOAbstract ! simplement avec context.commitTransaction() ? Cela peut poser des problèmes si d'autres classes héritent de TopiaDAOAbstract... Que faire donc ? Que pensez vous de ce problème ? Flo
On Mon, 25 May 2009 13:17:39 +0200 Florian DESBOIS <fdesbois@codelutin.com> wrote: ...
Que faire donc ? Que pensez vous de ce problème ?
Je me posais la question plus generalement sur les autres types de persistence que Hibernate dans ToPIA (dans notre cas flatfile). J'avais commence a l'ecrire pour etre sur que le code que je produissait de l'autre cote (hibernate) ne soit pas trop specifique hibernate et donc que l'on puisse plus tard utiliser d'autres moyens de persistence. Mais est-ce vraiment utile ? ne gagnerions nous pas en simplicite a faire sauter ce flatfile qui n'est de toute facon pas fonctionnelle et pas maintenu ? L'idee du flatfile etait au depart pour la gestion des scripts dans ISIS, mais en fait avec les different Storage on utilise pas du tout la persistence flatfile. Je pense donc qu'il serait mieux de faire moins generic :) (mieux -> plus simple). Et de remettre l'equivalent des ScriptStorages dans ToPIA si on en a besoin. Donc des le departs du projet on pourra s'appuyer soit sur la persistence de type hibernate (JPA), soit sur une persistence de type ScriptStorage. Mais que les deux ne se gere pas de la meme facon (a voir si sur le plus long terme on arrive pas tout de meme a trouver quelques points en commun) -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
Benjamin POUSSIN a écrit :
J'avais commence a l'ecrire pour etre sur que le code que je produissait de l'autre cote (hibernate) ne soit pas trop specifique hibernate et donc que l'on puisse plus tard utiliser d'autres moyens de persistence. Mais est-ce vraiment utile ? ne gagnerions nous pas en simplicite a faire sauter ce flatfile qui n'est de toute facon pas fonctionnelle et pas maintenu ?
Il m'avais aussi posé problème lors du passage hibernate 3.2 -> 3.3. J'avais fixé les erreurs de compilation, mais sans tester. -- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
J'ai besoin de cette modif, j'ai cependant remarquer quelque chose que je ne comprends pas en essayant, pour tester, d'implémenter les commitTransaction() et rollbackTransaction() (sur TopiaDAOAbstract ou TopiaDAOHibernate ce qui ne change rien) par : @Override public void commitTransaction() throws TopiaException { context.commitTransaction(); } Dans TopiaContextImpl ou se situe l'implémentation des commitTransaction et rollbackTransaction au niveau du context, se trouve ce bout de code dans chacune des deux méthodes (en remplacant la ligne qui va bien) : for (TopiaDAO<? extends TopiaEntity> dao : daoCache.values()) { dao.commitTransaction(); } Donc forcement ca boucle !! Je me demandais l'intérêt de ce "for" étant donné que les commitTransaction et rollbackTransaction sur les dao sont vide !! Y a t'il un intérêt particulier dans un certain cas ? Il me suffirait de supprimer la boucle for pour ne plus avoir de problème (notamment avec les tests). Qu'en pensez-vous ? Flo Le 25 mai 2009 14:29, Eric Chatellier <chatellier@codelutin.com> a écrit :
Benjamin POUSSIN a écrit :
J'avais commence a l'ecrire pour etre sur que le code que je produissait de l'autre cote (hibernate) ne soit pas trop specifique hibernate et donc que l'on puisse plus tard utiliser d'autres moyens de persistence. Mais est-ce vraiment utile ? ne gagnerions nous pas en simplicite a faire sauter ce flatfile qui n'est de toute facon pas fonctionnelle et pas maintenu ?
Il m'avais aussi posé problème lors du passage hibernate 3.2 -> 3.3. J'avais fixé les erreurs de compilation, mais sans tester.
-- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
_______________________________________________ Topia-devel mailing list Topia-devel@lists.labs.libre-entreprise.org http://lists.labs.libre-entreprise.org/mailman/listinfo/topia-devel
Bon en fait je viens de me rendre compte qu'il suffit que je fasse : dao.getContext().commitTransaction()... Dans ce cas, je ne comprend pas la difference (ou l'interet) de la methode dao.commitTransaction() ?!!? Le 27 mai 2009 11:49, Florian DESBOIS <fdesbois@codelutin.com> a écrit :
J'ai besoin de cette modif, j'ai cependant remarquer quelque chose que je ne comprends pas en essayant, pour tester, d'implémenter les commitTransaction() et rollbackTransaction() (sur TopiaDAOAbstract ou TopiaDAOHibernate ce qui ne change rien) par :
@Override public void commitTransaction() throws TopiaException { context.commitTransaction(); }
Dans TopiaContextImpl ou se situe l'implémentation des commitTransaction et rollbackTransaction au niveau du context, se trouve ce bout de code dans chacune des deux méthodes (en remplacant la ligne qui va bien) :
for (TopiaDAO<? extends TopiaEntity> dao : daoCache.values()) { dao.commitTransaction(); }
Donc forcement ca boucle !! Je me demandais l'intérêt de ce "for" étant donné que les commitTransaction et rollbackTransaction sur les dao sont vide !!
Y a t'il un intérêt particulier dans un certain cas ? Il me suffirait de supprimer la boucle for pour ne plus avoir de problème (notamment avec les tests).
Qu'en pensez-vous ?
Flo
Le 25 mai 2009 14:29, Eric Chatellier <chatellier@codelutin.com> a écrit :
Benjamin POUSSIN a écrit :
J'avais commence a l'ecrire pour etre sur que le code que je produissait de l'autre cote (hibernate) ne soit pas trop specifique hibernate et donc que l'on puisse plus tard utiliser d'autres moyens de persistence. Mais est-ce vraiment utile ? ne gagnerions nous pas en simplicite a faire sauter ce flatfile qui n'est de toute facon pas fonctionnelle et pas maintenu ?
Il m'avais aussi posé problème lors du passage hibernate 3.2 -> 3.3. J'avais fixé les erreurs de compilation, mais sans tester.
-- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
_______________________________________________ Topia-devel mailing list Topia-devel@lists.labs.libre-entreprise.org http://lists.labs.libre-entreprise.org/mailman/listinfo/topia-devel
On Wed, 27 May 2009 12:03:42 +0200 Florian DESBOIS <fdesbois@codelutin.com> wrote:
Bon en fait je viens de me rendre compte qu'il suffit que je fasse : dao.getContext().commitTransaction()...
Dans ce cas, je ne comprend pas la difference (ou l'interet) de la methode dao.commitTransaction() ?!!?
En fait tu prennais le probleme a l'envers :). On commit toujours un context, par contre le context previent ses DAO qu'il vient de commiter pour qu'eux puissent faire des choses. Dans le cas des flatfiles je pense qu'il sauvegardait les infos des entities modifier. On aurait pu/du utiliser un commit listener implanter par les DAO et enregistre sur le context pour faire ca. Il faudrait peut-etre mettre un bout de javadoc sur commitTransaction du DAO pour explique que c une methode de callback utilise pris par le context et non pas une methode qui fait un commit :) -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
Le Wed, 27 May 2009 13:16:54 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Wed, 27 May 2009 12:03:42 +0200 Florian DESBOIS <fdesbois@codelutin.com> wrote:
Bon en fait je viens de me rendre compte qu'il suffit que je fasse : dao.getContext().commitTransaction()...
Dans ce cas, je ne comprend pas la difference (ou l'interet) de la methode dao.commitTransaction() ?!!?
En fait tu prennais le probleme a l'envers :).
On commit toujours un context, par contre le context previent ses DAO qu'il vient de commiter pour qu'eux puissent faire des choses. Dans le cas des flatfiles je pense qu'il sauvegardait les infos des entities modifier.
On aurait pu/du utiliser un commit listener implanter par les DAO et enregistre sur le context pour faire ca.
Il faudrait peut-etre mettre un bout de javadoc sur commitTransaction du DAO pour explique que c une methode de callback utilise pris par le context et non pas une methode qui fait un commit :)
Et ne pas dire ça fonctionne pas quand on ne comprend pas comment ça marche :) Tout n'est pas parfait dans ToPIA, mais la plus part du temps, les gens qui ont écrit ToPIA ont un peu réfléchit avant de coder et donc souvent y'a une raison valable dans le code écrit (mais comme dit ben, il manque peut-être un peu de Javadoc...) Donc Florient pas d'enflammage ;)
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Topia-devel mailing list Topia-devel@lists.labs.libre-entreprise.org http://lists.labs.libre-entreprise.org/mailman/listinfo/topia-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Excuse moi, mais le nom de la méthode peut porter a confusion ceci-dit ! Et c'est FloriAN et pas FloriENT !! enfin c pas grave, chuis un ptit stagiaire qui fait des bêtises et qui apprend après tout :p Le 28 mai 2009 09:29, Tony Chemit <chemit@codelutin.com> a écrit :
Le Wed, 27 May 2009 13:16:54 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Wed, 27 May 2009 12:03:42 +0200 Florian DESBOIS <fdesbois@codelutin.com> wrote:
Bon en fait je viens de me rendre compte qu'il suffit que je fasse : dao.getContext().commitTransaction()...
Dans ce cas, je ne comprend pas la difference (ou l'interet) de la methode dao.commitTransaction() ?!!?
En fait tu prennais le probleme a l'envers :).
On commit toujours un context, par contre le context previent ses DAO qu'il vient de commiter pour qu'eux puissent faire des choses. Dans le cas des flatfiles je pense qu'il sauvegardait les infos des entities modifier.
On aurait pu/du utiliser un commit listener implanter par les DAO et enregistre sur le context pour faire ca.
Il faudrait peut-etre mettre un bout de javadoc sur commitTransaction du DAO pour explique que c une methode de callback utilise pris par le context et non pas une methode qui fait un commit :)
Et ne pas dire ça fonctionne pas quand on ne comprend pas comment ça marche :)
Tout n'est pas parfait dans ToPIA, mais la plus part du temps, les gens qui ont écrit ToPIA ont un peu réfléchit avant de coder et donc souvent y'a une raison valable dans le code écrit (mais comme dit ben, il manque peut-être un peu de Javadoc...) Donc Florient pas d'enflammage ;)
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Topia-devel mailing list Topia-devel@lists.labs.libre-entreprise.org http://lists.labs.libre-entreprise.org/mailman/listinfo/topia-devel
--
Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com _______________________________________________ Topia-devel mailing list Topia-devel@lists.labs.libre-entreprise.org http://lists.labs.libre-entreprise.org/mailman/listinfo/topia-devel
On Thu, 28 May 2009 10:36:01 +0200 Florian DESBOIS <fdesbois@codelutin.com> wrote:
Excuse moi, mais le nom de la méthode peut porter a confusion ceci-dit ! Et c'est FloriAN et pas FloriENT !! enfin c pas grave, chuis un ptit stagiaire qui fait des bêtises et qui apprend après tout :p
et qui profite de toutes les questions posees, pour modifier la javadoc, maintenir une FAQ et la doc ToPIA a jour ;) fallait pas commencer :D -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
Ok j'ai donc rajouté ca dans le FAQ.rst de Topia-persistence : Comment commit (ou rollback) une transaction directement à partir d'un DAO ? ============================================================================ Contrairement à ce que l'on pourrait croire aux premiers abords, les méthodes commitTransaction() et rollbackTransaction() disponibles dans les DAO ne sont pas prévus à cet effet. Il faut toujours utiliser le contexte pour commit (ou rollback) une transaction. Donc pour le faire à partir d'un DAO : dao.getContext().commitTransaction() // on récupère le context (transaction sur le DAO) et on commit. Le principe reste identique pour le rollback. Pour revenir sur les méthodes commitTransaction() et rollbackTransaction() disponibles sur le DAO, elles servent de "callback" au moment du commit (ou rollback) de la transaction. Le context se chargera d'appeler tous les commitTransaction() des DAO, ceci afin de permettre un traitement spécifique au DAO au moment du commit. Ce traitement peut donc être effectué directement à partir du dao via cette méthode sans passer par le context. JAVADOC dans TopiaDAODelegator dont herite tous les DAO générés : /** * Callback method when context was commited. * The DAO call his father to commitTransaction(). * The father of a DAO can be a TopiaDAOHibernate or TopiaDAOFlatfile. * This method was especially interesting for TopiaDAOFlatfile. * This method does nothing when father is a TopiaDAOHibernate. * @throws org.nuiton.topia.TopiaException * @see org.nuiton.persistence.TopiaDAOAbstract * @see org.nuiton.persistence.hibernate.TopiaDAOHibernate * @see org.nuiton.persistence.flatfile.TopiaDAOFlatfile */ @Override public void commitTransaction() throws TopiaException { getParentDAO().commitTransaction(); } /** * Callback method when context was rollback. * The DAO call his father to rollbackTransaction(). * The father of a DAO can be a TopiaDAOHibernate or TopiaDAOFlatfile. * This method was especially interesting for TopiaDAOFlatfile. * This method does nothing when father is a TopiaDAOHibernate. * @throws org.nuiton.topia.TopiaException * @see org.nuiton.persistence.TopiaDAOAbstract * @see org.nuiton.persistence.hibernate.TopiaDAOHibernate * @see org.nuiton.persistence.flatfile.TopiaDAOFlatfile */ @Override public void rollbackTransaction() throws TopiaException { getParentDAO().rollbackTransaction(); } Est-ce que cela résout le problème ? Au passage ca permet de montrer que j'ai bien compris mon erreur :p Le 28 mai 2009 11:51, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Thu, 28 May 2009 10:36:01 +0200 Florian DESBOIS <fdesbois@codelutin.com> wrote:
Excuse moi, mais le nom de la méthode peut porter a confusion ceci-dit ! Et c'est FloriAN et pas FloriENT !! enfin c pas grave, chuis un ptit stagiaire qui fait des bêtises et qui apprend après tout :p
et qui profite de toutes les questions posees, pour modifier la javadoc, maintenir une FAQ et la doc ToPIA a jour ;)
fallait pas commencer :D
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Topia-devel mailing list Topia-devel@lists.labs.libre-entreprise.org http://lists.labs.libre-entreprise.org/mailman/listinfo/topia-devel
participants (4)
-
Benjamin POUSSIN -
Eric Chatellier -
Florian DESBOIS -
Tony Chemit