Smalltalk › Pharo › Pharo Smalltalk Users

Voyage and instances retrieving

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

HilaireFernandes

Voyage and instances retrieving

Hi,

When iterating, with Smalltalk selectors, an object persisted in a
repository, some of its attributes (I guess because root for other
collection) are not resolved as expected at iteration. The Smalltalk
iteration does not work, returning empty result.

Fetching the whole model in memory will be an acceptable option. Is
there a global way to do this? I see the per attribute beEager but it
will be needed for a lot of attributes making not practical.

Thanks

Hilaire

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

http://drgeo.eu

HilaireFernandes

Re: Voyage and instances retrieving

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

http://drgeo.eu

EstebanLM

Re: Voyage and instances retrieving

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 <[hidden email]> 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
>
>

HilaireFernandes

Re: Voyage and instances retrieving

Hi Esteban,

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

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

http://drgeo.eu

EstebanLM

Re: Voyage and instances retrieving

> On 3 Mar 2017, at 10:00, Hilaire <[hidden email]> 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
>
>

HilaireFernandes

Re: Voyage and instances retrieving

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

http://drgeo.eu

EstebanLM

Re: Voyage and instances retrieving

> On 3 Mar 2017, at 12:17, Hilaire <[hidden email]> 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
>
>

HilaireFernandes

Re: Voyage and instances retrieving

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

http://drgeo.eu

EstebanLM

Re: Voyage and instances retrieving

> On 3 Mar 2017, at 17:24, Hilaire <[hidden email]> 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
>
>

HilaireFernandes

Re: Voyage and instances retrieving

Some more clues: in my application if I go in other part where these
attributes are used for some simulation, the attributes are resolved as
expected. Then when I go back the other part the select is working.

On more hints: the attribute collection seems to resolve fine, so proxy
is working, however the objects in collection come with attribute which
is a root, and it is this *one* which does not resolve. Of course when I
inspect it is resolved, but the select: bloc does not get it right.

I am pretty sure this part of the model is functional because these data
were previously persisted/restored just fine with Fuel.

I will try to dig for more clues.

Le 03/03/2017 à 17:50, Esteban Lorenzano a écrit :
> 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

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

http://drgeo.eu

HilaireFernandes

Re: Voyage and instances retrieving

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

http://drgeo.eu

EstebanLM

Re: Voyage and instances retrieving

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

> On 6 Mar 2017, at 18:34, Hilaire <[hidden email]> wrote:
>
> 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
>
>

HilaireFernandes

Re: Voyage and instances retrieving

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

http://drgeo.eu

EstebanLM

Re: Voyage and instances retrieving

> On 6 Mar 2017, at 18:56, Hilaire <[hidden email]> wrote:
>
> 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 :)

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

HilaireFernandes

Re: Voyage and instances retrieving

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

http://drgeo.eu