Voyage and duplicated entry
Locked
 
|
Hi,
I have strange behavior when saving object: when I edit then save, I got a duplicated entry in the repository collection. Some description about the object: This object class is part of a hierarchy class, where the top is defined as voyage root. In this object, hash and = are redefined. Any pointer? Hilaire -- Dr. Geo http://drgeo.eu |
|
Hi Hilaire, 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. Regards Sabine 2017-03-04 11:53 GMT+01:00 HilaireFernandes [via Smalltalk] <[hidden email]>:
|
Re: Voyage and duplicated entry
|
|
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 |
Re: Voyage and duplicated entry
|
|
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 |
|
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 <[hidden email]>: > > 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 > > > |
Re: Voyage and duplicated entry
|
|
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. Le 05/03/2017 à 12:52, Joachim Tuchel a écrit : > 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. -- Dr. Geo http://drgeo.eu |
Re: Voyage and duplicated entry
|
|
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 |
|
|
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? The only thing I could imagine is that Voyage somewhere uses = where it should use ==. But wouldn't many more people have problems then? 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:[hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 |
|
|
In reply to this post by HilaireFernandes
What about a simple test?
Load one of those objects anad assign it to a variable. Then change one of ist values and check if the one you have now is still == the other. ..it's a bit hard to explain, but I guess you know what I mean. 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:[hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 |
|
|
In reply to this post by HilaireFernandes
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 <[hidden email]>: > > 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 > > |
|
|
In reply to this post by jtuchel
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 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
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |