Hi Sabine, Norbert, It is nice to have feedbacks from other Voyagers ;) Thanks about the notice regarding reset on the repository. It may have implication I should be careful about, but not in my scenario because: - I start with empty collections in the repository, for the model part, - I import in the repository a model instance. The model instance comes from a Fuel document, - When I edit an instance (a person data), then save, I got a supplementary entry in the repo. No where in this scenario I execute a reset, at least from my code. I must stress the same instance duplication occurs when I inspect an instance, edit one attribute from the inspector, then save it from the inspector with "self save" command. Hilaire Le 04/03/2017 à 12:21, Sabine Manaa a écrit :

did you do VORepository current reset in the meantime?

If yes, this could be the reason. If you do this, the smalltalk cache of the objects is reset and the next time the objects are loaded again from mongo and then they are no longer "the same" objects within smalltalk. I had a hard time to learn this.

-- Dr. Geo http://drgeo.eu

Hilaire Sounds like this has nothing to do with voyage. If you modify part of on object's unique identifier, it's another object. The best you can do is to use a synthetic id that has no business meaning and use that for object identity. Joachim

Am 05.03.2017 um 12:02 schrieb Hilaire <hilaire@drgeo.eu>:

Situation looks a bit clearer. The duplicated object entries issue arises with two concomitant situations:

- the object reimplements hash and = methods - one of the attributes participating in the comparing protocol is modified.

In that scenario, Voyage guess it is dealing with a new element, even if it is not the case.

In some scenario, user really needs to override the comparing protocol, how to deal with the duplicated entries issue in that case?

Hilaire

...

Le 05/03/2017 à 10:19, Hilaire a écrit : I must stress the same instance duplication occurs when I inspect an instance, edit one attribute from the inspector, then save it from the inspector with "self save" command.

-- Dr. Geo http://drgeo.eu

The more I think the more it seems wrong to me. Whenever you ask an instance to save itself, if already in repo it should not duplicate itself whenever hash/= is overrided in this object. It does not sound as an expected behaviour. Hilaire Le 05/03/2017 à 14:51, Hilaire a écrit :

Understood. My use/understanding of hash and =, true in DrGeo, was more like unique identifier regarding its ontological characteristics (what distinguish it from other). So an exact same Point in DrGeo will have different hash value depending on its position on the plane, or it being free on a line, etc. May be I got it biased here.

Anyway problem solved, comparing protocol was just rampant code.

-- Dr. Geo http://drgeo.eu

Am 06.03.2017 um 18:10 schrieb jtuchel@objektfabrik.de:

Hilaire,

as soon as the hash of an object changes because you change an attribute that is used in the hash function, the object is not identical to its older ego any more, so Voyage cannot know it still is the same object (nor any other caching solution). Or am I wrong about this whole hash/= thing?

Yes :) You are mixing equality and identity. An object is identical if the memory location is the same. An object is equal whatever is defined in =/hash. In the default case classes do not overwrite =/hash so = and == return the same value. If you change the state of an object you might change the hash but not the identityHash. So it is identical but different to the version in the database hence should update the existing object and not creating a new one.

The only thing I could imagine is that Voyage somewhere uses = where it should use ==. But wouldn't many more people have problems then?

The problem is that we often use equality based collections where we should use identity based ones. These problems are hidden because = and == are the same for normal classes. As soon as you overwrite =/hash you experience problems because of that. So I have the impression that in general overwriting =/hash is not a good idea. Most of the time you mean "equal regarding to some context". In this case it is better to have your own equality selector like #isSameX:, #hasSameX: etc. Because the kernel classes rely on = equality you tear the semantics apart if yoou overwrite. Norbert

Joachim

Am 06.03.17 um 18:03 schrieb Hilaire:

...

The more I think the more it seems wrong to me. Whenever you ask an instance to save itself, if already in repo it should not duplicate itself whenever hash/= is overrided in this object. It does not sound as an expected behaviour.

Hilaire

Le 05/03/2017 à 14:51, Hilaire a écrit :

...

Understood. My use/understanding of hash and =, true in DrGeo, was more like unique identifier regarding its ontological characteristics (what distinguish it from other). So an exact same Point in DrGeo will have different hash value depending on its position on the plane, or it being free on a line, etc. May be I got it biased here.

Anyway problem solved, comparing protocol was just rampant code.

-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> Fliederweg 1 http://www.objektfabrik.de <http://www.objektfabrik.de/> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com <http://joachimtuchel.wordpress.com/> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Hilaire, I think you are right and I wonder why we didn't change it, yet. I can remember talking with Esteban about it. The culprit is that in VOCache the reversedObjects instance variable is a WeakKeyDictionary and not a WeakIdentityKeyDictionary. That is the reason why #isNew on an object returns true if equality is not the same. And this leads to object duplication. The whole purpose of the VOCache is to keep "identity" for the objects. So using an equality based collection is plain wrong. Norbert

Am 06.03.2017 um 18:03 schrieb Hilaire <hilaire@drgeo.eu>:

The more I think the more it seems wrong to me. Whenever you ask an instance to save itself, if already in repo it should not duplicate itself whenever hash/= is overrided in this object. It does not sound as an expected behaviour.

Hilaire

Le 05/03/2017 à 14:51, Hilaire a écrit :

...

Understood. My use/understanding of hash and =, true in DrGeo, was more like unique identifier regarding its ontological characteristics (what distinguish it from other). So an exact same Point in DrGeo will have different hash value depending on its position on the plane, or it being free on a line, etc. May be I got it biased here.

Anyway problem solved, comparing protocol was just rampant code.

-- Dr. Geo http://drgeo.eu