Gros probleme avec topia et topiaId
Salut, Je viens d'apprendre qu'il y a un GROS con (et je pese mes mots) qui vient de renommer topiaId en id. Et cela sans demander rien a personne ni en parler. Vous pensez quoi, que les choses ont ete faite par hazard dans le temps ? Si ca s'appelle topiaId il y a une raison. Il faut donc modifier le plus vite possible le code pour que id redevienne topiaId. MERCI D'AVANCE. -- 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 mercredi 19 mai 2010 à 17:30 +0200, Benjamin POUSSIN a écrit :
Salut,
Je viens d'apprendre qu'il y a un GROS con (et je pese mes mots) qui vient de renommer topiaId en id. Et cela sans demander rien a personne ni en parler.
Merci , toujours agréable de se faire insulter gratuitement. Sinon j'en ai déjà discuté avec Tony et on a fait quelques essais concluant sur le trunk donc... De plus le champs s'appelle toujours topiaId, rien n'a changé à par le nom des getter/setter pour éviter d'avoir le mot clé topia un peu partout.
Vous pensez quoi, que les choses ont ete faite par hazard dans le temps ?
Si ca s'appelle topiaId il y a une raison. Il faut donc modifier le plus vite possible le code pour que id redevienne topiaId.
Quelle est cette raison ?
MERCI D'AVANCE.
-- Florian Desbois <fdesbois@codelutin.com> SSLL Code Lutin Tel: 02 40 50 29 28 http://www.codelutin.com Membre du Réseau Libre-entreprise
On 19/05/2010 17:44, Florian Desbois wrote:
Merci , toujours agréable de se faire insulter gratuitement. Sinon j'en ai déjà discuté avec Tony et on a fait quelques essais concluant sur le trunk donc...
De plus le champs s'appelle toujours topiaId, rien n'a changé à par le nom des getter/setter pour éviter d'avoir le mot clé topia un peu partout C'est presque pire :) Il y a une non-correpondance javabean.
Dans les mapping hibernate par exemple s'il y a un attribut "topiaId" hibernate utilise getTopiaId()/setTopiaId(). Ça doit donc encore fonctionner parce que hibernate utilise encore le code déprécié. -- Éric<chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
Le Wed, 19 May 2010 18:12:53 +0200, Eric Chatellier <chatellier@codelutin.com> a écrit :
On 19/05/2010 17:44, Florian Desbois wrote:
Merci , toujours agréable de se faire insulter gratuitement. Sinon j'en ai déjà discuté avec Tony et on a fait quelques essais concluant sur le trunk donc...
De plus le champs s'appelle toujours topiaId, rien n'a changé à par le nom des getter/setter pour éviter d'avoir le mot clé topia un peu partout C'est presque pire :) Il y a une non-correpondance javabean. Non ça reste conforme javabean :
si t'as un getId et setId , alors tu a une propriété javabean id , rien à voir avec le nom d'un champ ;)
Dans les mapping hibernate par exemple s'il y a un attribut "topiaId" hibernate utilise getTopiaId()/setTopiaId(). Ça doit donc encore fonctionner parce que hibernate utilise encore le code déprécié.
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le mercredi 19 mai 2010 à 18:12 +0200, Eric Chatellier a écrit :
On 19/05/2010 17:44, Florian Desbois wrote:
Merci , toujours agréable de se faire insulter gratuitement. Sinon j'en ai déjà discuté avec Tony et on a fait quelques essais concluant sur le trunk donc...
De plus le champs s'appelle toujours topiaId, rien n'a changé à par le nom des getter/setter pour éviter d'avoir le mot clé topia un peu partout C'est presque pire :) Il y a une non-correpondance javabean.
Dans les mapping hibernate par exemple s'il y a un attribut "topiaId" hibernate utilise getTopiaId()/setTopiaId(). Ça doit donc encore fonctionner parce que hibernate utilise encore le code déprécié.
Le code est déprécié uniquement dans les interfaces. A moins que je me trompe, Hibernate utilise les Impl, donc les getTopiaId()/setTopiaId() seront toujours la. -- Florian Desbois <fdesbois@codelutin.com> SSLL Code Lutin Tel: 02 40 50 29 28 http://www.codelutin.com Membre du Réseau Libre-entreprise
Le Wed, 19 May 2010 17:30:02 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
Salut,
Je viens d'apprendre qu'il y a un GROS con (et je pese mes mots) qui vient de renommer topiaId en id. Et cela sans demander rien a personne ni en parler. Y'a une évolution sur nuiton :
http://nuiton.org/issues/show/578
Vous pensez quoi, que les choses ont ete faite par hazard dans le temps ?
Si ca s'appelle topiaId il y a une raison. Il faut donc modifier le plus vite possible le code pour que id redevienne topiaId.
MERCI D'AVANCE.
Le gros con c'est pas moi :) mais j'étais d'accord avec le gros con pour faire ce changement :) Il s'agit en fait juste le nom des getters-setters qui changent, mais certainement pas le nom de la propriété topiaId. On reste bien sur du topiaId en base . Sachant cela, Cela te pose-t-il un problème ? Pour moi c'est ok car si on veut un jour arriver à s'abstraire de ToPIA, il va bien falloir des getter autres que getTopiaId... donc getId() c'est neutre et ça me va. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le Wed, 19 May 2010 17:48:44 +0200, Tony Chemit <chemit@codelutin.com> a écrit :
Il s'agit en fait juste le nom des getters-setters qui changent, mais certainement pas le nom de la propriété topiaId.
On reste bien sur du topiaId en base .
Sachant cela, Cela te pose-t-il un problème ?
Pour moi c'est ok car si on veut un jour arriver à s'abstraire de ToPIA, il va bien falloir des getter autres que getTopiaId...
donc getId() c'est neutre et ça me va.
Si id est trop problématique, on pourrait pas utiliser technicalId ? -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Wed, 19 May 2010 18:03:52 +0200 Tony Chemit <chemit@codelutin.com> wrote:
Sachant cela, Cela te pose-t-il un problème ?
Pour moi c'est ok car si on veut un jour arriver à s'abstraire de ToPIA, il va bien falloir des getter autres que getTopiaId...
donc getId() c'est neutre et ça me va.
Si id est trop problématique, on pourrait pas utiliser technicalId ?
Oui getId() est tres problematique, c'est exactement ca, Donc autant utiliser topiaId car comme ca, ca fait de la pub en plus. Le cout/gain pour modifier topiaId en autre chose est beaucoup trop important pour le faire. Gain environs 0, cout environs enorme :( Donc on garde topiaId. Au pire du pire, j'accepterais peut-etre un getTechnicalId() en plus, mais du coup c redondant, deux facons de faire donc mauvaise facon. Si tu le veux vraiment, tu ajoutes dans tes classes impl (seulement de ton projet, pas dans les templates) un: getTechnicalId() { return getTopiaId();} Mais pour moi c'est vraiment affreux de faire ca :( Et pourquoi vouloir s'abstraire d'une abstraction ? Topia est justement la pour s'abstraire de la persistence du moment (DBManager, JDO, Hibernate, JPA). Car si on commence a vouloir s'abstraire d'une abstraction, je ne sais pas ou on va finir :(. (sans doute tres proche de l'usine a gaz :() Et si les projets etaient bien fait, ils n'utiliseraient pas le topiaId, mais la cle metier et donc jamais getTopiaId ne serait appele dans ton projet. (bon ok, la je pousse un peu :D, mais dans l'idee, ce n'est pas totalement faux) -- 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 19/05/2010 18:03, Tony Chemit a écrit :
Le Wed, 19 May 2010 17:48:44 +0200, Tony Chemit<chemit@codelutin.com> a écrit :
Il s'agit en fait juste le nom des getters-setters qui changent, mais certainement pas le nom de la propriété topiaId.
On reste bien sur du topiaId en base .
Sachant cela, Cela te pose-t-il un problème ?
Pour moi c'est ok car si on veut un jour arriver à s'abstraire de ToPIA, il va bien falloir des getter autres que getTopiaId...
donc getId() c'est neutre et ça me va.
Si id est trop problématique, on pourrait pas utiliser technicalId ? Sur sandra, (je ne sais pas si c'était une bonne idée...) une de mes entité a le champ "id", je me retrouve avec cette erreur à la compile :
.../com/cybelia/sandra/entities/LabelAbstract.java:[46,28] reference to ID is ambiguous, both variable ID in org.nuiton.topia.persistence.TopiaEntity and variable ID in com.cybelia.sandra.entities.Label match Donc, même après migration, je ne peux toujours pas bosser sur le trunk de topia :( Sylvain
Le jeudi 20 mai 2010 à 11:20 +0200, letellier a écrit :
Donc, même après migration, je ne peux toujours pas bosser sur le trunk de topia :(
Refactor effectué. -- Florian Desbois <fdesbois@codelutin.com> SSLL Code Lutin Tel: 02 40 50 29 28 http://www.codelutin.com Membre du Réseau Libre-entreprise
On Thu, 20 May 2010 14:36:45 +0200 Florian Desbois <fdesbois@codelutin.com> wrote:
Le jeudi 20 mai 2010 à 11:20 +0200, letellier a écrit :
Donc, même après migration, je ne peux toujours pas bosser sur le trunk de topia :(
Refactor effectué.
merci florian -- 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
participants (5)
-
Benjamin POUSSIN -
Eric Chatellier -
Florian Desbois -
letellier -
Tony Chemit