Quantcast

Dealing with object equality and proxies

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Dealing with object equality and proxies

Esteban A. Maringolo
This might sound a little naive considering I'm using GLORP in production for almost a year.

But how do you deal with equality of your objects? 

Do you have any special recommendation?

I always use the default implementation inherited from Object, which relies on object identity (#==).

But I think proxies are playing with me here.

NOTE: All these examples happen in the context of the same GlorpSession.

"If I do this, it works as expected:"
(session read: MyClass) select: [ :each | each supervisor = aSupervisor].

"But if I do this it doesnt:"
(session read: MyClass) select: [ :each | aSupervisor = each supervisor ].
 
The same happens if there is a proxied reference and I use it in a where clause:
E.g. anEmployee supervisor -> aSupervisor

"This returns an empty collection."
(session read: MyClass) select: [ :each | each supervisor = anEmployee supervisor ].

"Ensuring materialization returns the proper collection."
(session read: MyClass) select: [ :each | each supervisor = anEmployee supervisor yourSelf].


You might ask why not using a GlorpExpression as a where clause, like in: 
session read: MyClass where: [ :each | each supervisor = anEmployee supervisor].

I don't because sometimes I cache the result of (session read: MyClass) to avoid roundtrips and read everything in one shot, so in-memory filtering is faster than having to pull the data from the DB each time.

Do you have any advice in favor/against this way of working?

Thank you!

--
Esteban.






--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dealing with object equality and proxies

Alan Knight-2
Yes, that's an issue. The typical workaround is to send #yourself. So 
  
(session read: MyClass) select: [ :each | aSupervisor yourself = each supervisor yourself ].

If your dialect inlines #yourself (VA does), so it doesn't do anything, then Glorp conveniently defines #yourSelf for the same purpose.

On 8 October 2014 16:59, Esteban A. Maringolo <[hidden email]> wrote:
This might sound a little naive considering I'm using GLORP in production for almost a year.

But how do you deal with equality of your objects? 

Do you have any special recommendation?

I always use the default implementation inherited from Object, which relies on object identity (#==).

But I think proxies are playing with me here.

NOTE: All these examples happen in the context of the same GlorpSession.

"If I do this, it works as expected:"
(session read: MyClass) select: [ :each | each supervisor = aSupervisor].

"But if I do this it doesnt:"
(session read: MyClass) select: [ :each | aSupervisor = each supervisor ].
 
The same happens if there is a proxied reference and I use it in a where clause:
E.g. anEmployee supervisor -> aSupervisor

"This returns an empty collection."
(session read: MyClass) select: [ :each | each supervisor = anEmployee supervisor ].

"Ensuring materialization returns the proper collection."
(session read: MyClass) select: [ :each | each supervisor = anEmployee supervisor yourSelf].


You might ask why not using a GlorpExpression as a where clause, like in: 
session read: MyClass where: [ :each | each supervisor = anEmployee supervisor].

I don't because sometimes I cache the result of (session read: MyClass) to avoid roundtrips and read everything in one shot, so in-memory filtering is faster than having to pull the data from the DB each time.

Do you have any advice in favor/against this way of working?

Thank you!

--
Esteban.






--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dealing with object equality and proxies

Esteban A. Maringolo
2014-10-08 21:32 GMT-03:00 Alan Knight <[hidden email]>:
>
> Yes, that's an issue. The typical workaround is to send #yourself. So
>
> (session read: MyClass) select: [ :each | aSupervisor yourself = each supervisor yourself ].
>
> If your dialect inlines #yourself (VA does), so it doesn't do anything, then Glorp conveniently defines #yourSelf for the same purpose.

It's good to know this is a recognized issue. I'm doing that using
#yourSelf in Pharo 3.


I'm just thinking aloud... couldn't Proxy (or a specific subclass of
it) implement #= in terms of the primary key (usually a surrogate id
column) to avoid materialization just for comparison?

That way I would be able to compare two proxies without having to
materialize any of the references.
I know this should be done very carefully, but if two proxies point to
the same reference (Eg. ClassA, ID=X), you can implement #= in terms
of comparing the referenced class and the id.

But proxies work in terms of Queries, and I don't know whether you can
compare if two queries are the same...


Anyway, thank you Alan!

Esteban A. Maringolo

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dealing with object equality and proxies

Alan Knight-2
Normally proxies (at least to a single object) only work with a primary key query. So even if it issues the query it would be a cache hit if the object is in memory, so not very much work.



On 8 October 2014 17:49, Esteban A. Maringolo <[hidden email]> wrote:
2014-10-08 21:32 GMT-03:00 Alan Knight <[hidden email]>:
>
> Yes, that's an issue. The typical workaround is to send #yourself. So
>
> (session read: MyClass) select: [ :each | aSupervisor yourself = each supervisor yourself ].
>
> If your dialect inlines #yourself (VA does), so it doesn't do anything, then Glorp conveniently defines #yourSelf for the same purpose.

It's good to know this is a recognized issue. I'm doing that using
#yourSelf in Pharo 3.


I'm just thinking aloud... couldn't Proxy (or a specific subclass of
it) implement #= in terms of the primary key (usually a surrogate id
column) to avoid materialization just for comparison?

That way I would be able to compare two proxies without having to
materialize any of the references.
I know this should be done very carefully, but if two proxies point to
the same reference (Eg. ClassA, ID=X), you can implement #= in terms
of comparing the referenced class and the id.

But proxies work in terms of Queries, and I don't know whether you can
compare if two queries are the same...


Anyway, thank you Alan!

Esteban A. Maringolo

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Loading...