On Mon, 04 May 2009 16:50:50 +0200 Arnaud Thimel <thimel@codelutin.com> wrote:
Tony Chemit a écrit :
Moi :) les clef uniques pour mes validateurs ne seront plus basé directement sur les associations mais sur les topia ids des associations ;) et là tout fonctionnera bien
Moi j'aurai été assez pour baser le hashCode sur le topiaId. Si je reprends l'idée de Benjamin, c'est qu'il y a un laps de temps entre la création de l'objet et l'assignation de son topiaId, du coup calcul du hashCode avec : impossible ? Quel risque on a ? Si un objet est pas trouvé la première fois il va parcourir toute la liste, mais normalement, on assigne tout de suite un topiaId à une entité ?
Oui, je ne suis pas contre, mais si ca pas ete fait comme ca c qu'il y a une raison :). Mais je ne me rappelle plus exactement laquel :(. Il me semble que lors de la creation d'une entity, chez nous ca poserait pas de probleme (c justement ce que je disais qu'il fallait verifier). Mais le but etait aussi que topia puisse fonctionner avec des ID qui ne serait pas des topia ID, et donc assigne par exemple lors de la sauvegarde en base. Et du coupe le code suivant fait un magnique memory leak :(: entity = dao.create(); hashset.add(entity); ... entity.save(); ... hashset.remove(entity); car entre le add et le remove le hash a change car l'id a change car assigne au moment du save. Et donc lorsqu'on fait le remove le Set ne retrouve pas l'entite car la premiere recherche se fait sur le hash. rem: avec un Vector/ArrayList/... ca n'arriverait pas :) Et donc la seul chose vraiment stable est la date de creation de l'entite, qui est defini des la creation et qui ne varie pas. De plus elle est presque unique donc pas mauvaise (date de creation en milliseconde, y'a pas des tas d'objet cree en 1ms :)
Tony, j'ai du mal à comprendre ton histoire de uniqueKeyHashCode, surtout au niveau du rôle de "this.keys".
oui, pareil :)
Mais d'après ca : getFieldValue(key, o); si on change une valeur de l'entité, le hashCode change ?
ce qui est tres, tres mauvais :(
Sinon pour le fait qu'un hashCode doit être immuable dans un runtime d'une appli, pour moi le fait qu'il soit immuable sur toute sa vie, c'est pas plus mal, dans le sens que : "qui peut le plus peut le moins" ?
Le immutable dans le runtime du au fait explique plus haut. Mais je trouve que c encore mieux s'il ne varie jamais. Car par exemple si on serialise une HashMap ou un HashSet. Et que les hash changes entre deux execution, la serialisation ne sert strictement a rien, car aucun objet ne pourra etre retrouve :( Dans ton cas, ou en fait du ne souhaite pas vraiment utilise le hash mais avec quelque chose d'unique, le topiaId est la bonne solution :). Et il faut bien toujours avoir en tete que A !=B n'implique pas A.hash != B.hash. -- 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