Hi Hilaire, I do not understand well your problem. Which query do you want to implement? cheers! Esteban

On 2 Mar 2017, at 21:32, Hilaire <hilaire@drgeo.eu> wrote:

Problem seems related to object identity, which imply a primitive call in Object>== message. Si I guess it may not let a chance to Voyage to resolve to the the real object but stay at it 'proxy-oid-whatever' stuff.

Non working code looks like:

myObjectInRepo select: [ :each | someObjects includes: each anAttribute "the one Voyage should fetch"]

I guess implementing = and hash in the anAttribute class will resolve the issue, but it will be slower, and an uneeded feature.

Any alternative idea?

Hilaire

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

On 3 Mar 2017, at 10:00, Hilaire <hilaire@drgeo.eu> wrote:

Hi Esteban,

I want to select some objects with code Smalltalk selectors, as bellow.

why? you cannot transform that into a mongo query? something like: myObjectInRepo select: [ :each | (each at: ‘attribute’) in: someObjectsCollection ] Esteban

In the code bellow, myObjectInRepo is already fetched from the repo (so it is in the image), but the select: return an empty list, but it should not be empty.

myObjectInRepo select: [ :each | someObjects includes: each anAttribute "the one Voyage should fetch"]

Hilaire

Le 02/03/2017 à 21:58, Esteban Lorenzano a écrit :

...

Hi Hilaire,

I do not understand well your problem. Which query do you want to implement?

cheers! Esteban

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

On 3 Mar 2017, at 12:17, Hilaire <hilaire@drgeo.eu> wrote:

Hi Esteban,

I could, but I don't understand why the attribute does not resolve to an object equals to the other one in memory.

if you have objects in memory you can do MyRoot selectAll select: [ :each | whateverYouWantBecauseYouAreInPharo ]. but if you do MyRoor selectMany: [ :each | … here you need to apply a mongo query, you will not have the objects until query is executed and result is retrieved ] Esteban

If I add an inspect to the attributes, it resolves correctly and code work as expected:

myObjectInRepo select: [ :each | each anAttribute inspect. someObjects includes: each anAttribute "the one Voyage should fetch"]

There is some lazyness in resolving the object.

I implemented = to bypass the == and primivite but it does not help.

For efficiency and special aspect of the model, I prefer to stick to the Smalltalk iterators when possible.

Hilaire

Le 03/03/2017 à 12:02, Esteban Lorenzano a écrit :

...

why? you cannot transform that into a mongo query?

something like:

myObjectInRepo select: [ :each | (each at: ‘attribute’) in: someObjectsCollection ]

Esteban

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

On 3 Mar 2017, at 17:24, Hilaire <hilaire@drgeo.eu> wrote:

I don't understand why I should use a query! I already have an instance of the object fetched from the repo but its attributes are not resolved when read from an iterator block: I can't pick up the one I want.

mmm, attributes have to be solved, otherwise you have a problem… I mean, when you bring an object from mongo, it will fetch also all attributes (in case those attributes are collections it will bring a proxy but it will solve it as soon as you ask something to them, so is transparent to you). So, there is something that is not working in your model, I think… Esteban

These attributes are not root, to the contrary to what I wrote initially.

Hilaire

Le 03/03/2017 à 12:29, Esteban Lorenzano a écrit :

...

if you have objects in memory you can do

MyRoot selectAll select: [ :each | whateverYouWantBecauseYouAreInPharo ].

but if you do

MyRoor selectMany: [ :each | … here you need to apply a mongo query, you will not have the objects until query is executed and result is retrieved ]

Esteban

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

Le 03/03/2017 à 18:09, Hilaire a écrit :

I will try to dig for more clues.

Now that I clarified the issues regarding duplicated entries and Date. I took another look to this problem. After reset of the repo, to test for sure Voyage correctly retrieves the attributes, I face the same issue again. The attributes of an object, itself a collection attribute of an object in the repo, are not materialized. The code bellow does not work as expected. Some details on the involved object: someAdults is a collection of adult objects (saved in their own Participant collection in the repo and already retrieved); expenses is an attribute of a Contract instance (the later save in its own collection too); owner returns an adult,and I think it is the one that does not materialize.

expensesOf: someAdults ^ expenses select: [ :anExpense | someAdults includes: anExpense owner]

Voyage appears to be lazy to materialize it, and indeed the changed code bellow makes the materialization to take place:

expensesOf: someAdults ^ expenses select: [ :anExpense | someAdults includes: anExpense owner value ]

Of course it can't be a solution because I will not know for sure when selection will work or fail. So far I only see the problem in two places, and I have a lot of selection code. Hilaire -- Dr. Geo http://drgeo.eu

Ah, sorry I was not clear enough in my introduction. Obviously, I removed all =/hash overrides on the involved objects and it is therefore an orthogonal issue (that's why I first resolved the other issues first). Or did you mean something I did not understand in your previous message? Hilaire Le 06/03/2017 à 18:45, Esteban Lorenzano a écrit :

just as a side note:

you must NEVER do a hash based in an attribute that might change. You will screw not just Voyage but all collections where your object is stored (except Array).

Esteban

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

I'll make a test case to illustrate the issue. Hilaire Le 06/03/2017 à 19:05, Esteban Lorenzano a écrit :

...

Ah, sorry I was not clear enough in my introduction. Obviously, I removed all =/hash overrides on the involved objects and it is therefore an orthogonal issue (that's why I first resolved the other issues first). Or did you mean something I did not understand in your previous message? no, I didn’t understood you removed #= and #hash :)

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