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. |
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:
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. |
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. |
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]>: 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. |
Free forum by Nabble | Edit this page |