TopiaDao.delete(e) si e.isPersisted() == false ?
Si on appelle TopiaDao.delete(e) alors que e.isPersisted() == false ça pète mais ça pète bizarrement. En disant que un object est transient alors qu'il fait un find. J'ai mis deux heures pour comprendre qu'en fait c'est l'objet que j'essaiyais de delete qui était transient :-( Je vous propose au choix : * dans delete(e) : Preconditions.checkArguement(e.isPertisted()) (on pète) mais pour la vraie raison) * dans delete(e) : on englobe tout le code dans if (e.isPertisted()) du coup, si l'objet n'était pas créé, on ne fait rien pour le supprimer. Pour moi, c'est plutôt la première solution. Qu'en pensez-vous ? -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
Le 28/11/2013 11:18, Brendan Le Ny a écrit :
Si on appelle TopiaDao.delete(e) alors que e.isPersisted() == false ça pète mais ça pète bizarrement. En disant que un object est transient alors qu'il fait un find. J'ai mis deux heures pour comprendre qu'en fait c'est l'objet que j'essaiyais de delete qui était transient :-(
Je vous propose au choix : * dans delete(e) : Preconditions.checkArguement(e.isPertisted()) (on pète) mais pour la vraie raison) * dans delete(e) : on englobe tout le code dans if (e.isPertisted()) du coup, si l'objet n'était pas créé, on ne fait rien pour le supprimer.
Pour moi, c'est plutôt la première solution. Qu'en pensez-vous ? Idem.
Au moins si quelque chose ne va pas, l'utilisateur le saura. Arnaud
Le 28/11/2013 11:18, Brendan Le Ny a écrit :
* dans delete(e) : Preconditions.checkArguement(e.isPertisted()) (on pète) mais pour la vraie raison)
Commité en rev 2905. Codé sans Guava pour éviter de tirer la dép dans le projet qui utilise Topia. -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
On Mon, 02 Dec 2013 11:10:12 +0100 Brendan Le Ny <bleny@codelutin.com> wrote:
Le 28/11/2013 11:18, Brendan Le Ny a écrit :
* dans delete(e) : Preconditions.checkArguement(e.isPertisted()) (on pète) mais pour la vraie raison)
Commité en rev 2905. Codé sans Guava pour éviter de tirer la dép dans le projet qui utilise Topia.
Je ne comprends pas, on utilise Guava en interne (pour preuve ton dernier commit [1]) dans le framework, donc fatalement l'utilisateur va tirer guava. Si on ne veut pas (plus?) de Guava il faut le faire complètement, non? Perso, ça ne me dérange pas d'utiliser Guava. tony. [1] http://nuiton.org/projects/topia/repository/revisions/2906
Le 03/12/2013 10:23, Tony Chemit a écrit :
Je ne comprends pas, on utilise Guava en interne (pour preuve ton dernier commit [1]) dans le framework, donc fatalement l'utilisateur va tirer guava.
On peut l'utiliser en interne. Guava sera tiré en dépendance transitive mais l'utilisateur ne sera pas obligé de l'ajouter dans le pom de son projet. Si on génère du code qui tire Guava, alors l'utilisateur devient obligé d'ajouter Guava dans son pom, je préfère que topia n'oblige pas à déclarer des déps (ou le moins possible). -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
On Tue, 03 Dec 2013 10:28:07 +0100 Brendan Le Ny <bleny@codelutin.com> wrote:
Le 03/12/2013 10:23, Tony Chemit a écrit :
Je ne comprends pas, on utilise Guava en interne (pour preuve ton dernier commit [1]) dans le framework, donc fatalement l'utilisateur va tirer guava.
On peut l'utiliser en interne. Guava sera tiré en dépendance transitive mais l'utilisateur ne sera pas obligé de l'ajouter dans le pom de son projet. dépendance transitive is evil :(
Si on génère du code qui tire Guava, alors l'utilisateur devient obligé d'ajouter Guava dans son pom, je préfère que topia n'oblige pas à déclarer des déps (ou le moins possible).
Ok il faudrait peut-être alors faire une passe pour bien vérifier qu'on ne tire rien d'autre (commons-lang3, commons-collections,...) Mais bon au final l'utilisateur a quand même guava dans son class-path, si il ne fait pas de check de dependances il n'y verra que du feu. Je pensais alors plus à des applications qui voudrait minimiser la taille du class-path. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
Le 03/12/2013 10:28, Brendan Le Ny a écrit :
Si on génère du code qui tire Guava, alors l'utilisateur devient obligé d'ajouter Guava dans son pom, je préfère que topia n'oblige pas à déclarer des déps (ou le moins possible). +1 : pure java.
-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
Le Tue, 03 Dec 2013 10:28:07 +0100, Brendan Le Ny <bleny@codelutin.com> a écrit :
Le 03/12/2013 10:23, Tony Chemit a écrit :
Je ne comprends pas, on utilise Guava en interne (pour preuve ton dernier commit [1]) dans le framework, donc fatalement l'utilisateur va tirer guava.
On peut l'utiliser en interne. Guava sera tiré en dépendance transitive mais l'utilisateur ne sera pas obligé de l'ajouter dans le pom de son projet.
Si on génère du code qui tire Guava, alors l'utilisateur devient obligé d'ajouter Guava dans son pom, je préfère que topia n'oblige pas à déclarer des déps (ou le moins possible).
Je suis d'accord avec toi : obliger à déclarer des deps, c'est pas terrible. Mais ça reste dommage de se passer de librairies et de refaire des choses qui ont déjà été faites, refaites, approuvées et que nous même avons du mal à nous passer. Je rejoins Tony : dans la logique, faut faire le tour des possibles librairies qu'on peut déjà tirer pour être bien sur. Et si nous partons dans l'idée que certaines dépendances feraient mieux de rester, faudrait sans doute préciser clairement sur le site de topia que ces librairies sont nécessaires (ou du moins tirées transitivement) -- Yannick Martel
Le 03/12/2013 10:53, Yannick Martel a écrit :
Mais ça reste dommage de se passer de librairies et de refaire des choses qui ont déjà été faites, refaites, approuvées et que nous même avons du mal à nous passer.
Euh, en l'occurrence, il s'agit de ce code là : if ( ! entity.isPersisted()) { throw new IllegalArgumentException("entity " + entity + " is not persisted, you can't delete it"); } Je pense qu'on peut raisonnablement se passer de Guava pour ça. Après j'suis d'accord avec toi et Éric, faut essayer au max de faire des purs POJO, après si on se rend compte qu'il faut absolument une lib, bah faut pas se priver. -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
participants (5)
-
Arnaud Thimel -
Brendan Le Ny -
Eric Chatellier -
Tony Chemit -
Yannick Martel