Voyage and duplicated entry

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Voyage and duplicated entry

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|

Re: Voyage and duplicated entry

Sabine Manaa
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]>:
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





If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Voyage-and-duplicated-entry-tp4937268.html
To start a new topic under Pharo Smalltalk Users, email [hidden email]
To unsubscribe from Pharo Smalltalk Users, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Voyage and duplicated entry

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|

Re: Voyage and duplicated entry

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|

Re: Voyage and duplicated entry

jtuchel
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
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Voyage and duplicated entry

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|

Re: Voyage and duplicated entry

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|

Re: Voyage and duplicated entry

jtuchel
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


Reply | Threaded
Open this post in threaded view
|

Re: Voyage and duplicated entry

jtuchel
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


Reply | Threaded
Open this post in threaded view
|

Re: Voyage and duplicated entry

NorbertHartl
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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Voyage and duplicated entry

NorbertHartl
In reply to this post by jtuchel

Am 06.03.2017 um 18:10 schrieb [hidden email]:

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          [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