Re: Qualifier Evaluation with Object in Multiple Editing Contexts
Re: Qualifier Evaluation with Object in Multiple Editing Contexts
- Subject: Re: Qualifier Evaluation with Object in Multiple Editing Contexts
- From: Aaron Rosenzweig via Webobjects-dev <email@hidden>
- Date: Fri, 31 May 2019 21:09:52 -0400
At the base of it - if you do “.equals()” with one EO and another… even if they
generate the same GlobalID they will not be equal if they are in different
editingContexts.
So that’s why an in memory evaluation doesn’t work.
When you query the database, there is no EC in that realm, so you get a
different behavior.
Some people call this a form of “impedance mismatch” when traversing the java
object world into the SQL relational world.
Mixing EOs of disparate contexts is a bit like crossing the beams in
Ghostbusters - don’t want to do it.
Your pull request would trick you thinking you haven’t crossed beams and later
run into an issue if you try to assign and then save. A type of “kick the
problem down the road” scenario.
For me - it’s code smell when the objects aren’t in the same EOEditingContext
and I’d like to know sooner, rather than later.
AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/>
e: email@hidden <mailto:email@hidden> t: (301) 956-2319
> On May 31, 2019, at 2:37 PM, Henrique Prange via Webobjects-dev
> <email@hidden> wrote:
>
> Hi Paul,
>
> Thanks for your feedback. It's good to know that I'm not alone. :) Even
> though it's an unusual situation, I wondered if someone else hasn't been
> bitten by it too.
>
> I'll create a pull request for discussion. Fixing the problem for toOne
> relationships is not complicated. I'm looking at the ERXComparisonSupport
> class for reference. Fixing the same problem for a collection of EOs (toMany
> relationships) is a little bit more tricky. I'll give more details in the
> pull request.
>
> Cheers,
>
> HP
>
>> On May 28, 2019, at 11:41 PM, Paul Hoadley <email@hidden
>> <mailto:email@hidden>> wrote:
>>
>> Hi Henrique,
>>
>> On 21 May 2019, at 08:22, Henrique Prange <email@hidden
>> <mailto:email@hidden>> wrote:
>>
>>> I've been using the EOQualifier.evaluateWithObject method to filter some
>>> EOs in memory. Everything works fine except for one particular case. It
>>> always returns false if I try to evaluate a qualifier containing EOs with
>>> an EO from another editing context.
>>>
>>> The code below demonstrates the problem:
>>>
>>> EOEditingContext ec1 = // create new ERXEC;
>>> Foo foo = ... // Fetch Foo using ec1
>>> EOQualifier q = Bar.FOO.is <http://bar.foo.is/>(foo);
>>>
>>> EOEditingContext ec2 = // create new ERXEC;
>>> Bar bar = ... // Fetch bar related to foo using ec2
>>>
>>> q.evaluateWithObject(bar); // returns false
>>> ERXEOControlUtilities.eoEquals(bar.foo(), foo); // returns true
>>>
>>> The qualifier evaluates to false because the editing contexts of bar.foo()
>>> and foo are different, even though their EOGlobalIDs are the same.
>>
>> That's certainly an interesting result.
>>
>>> This behavior is not consistent with the result of the same qualifier being
>>> applied to a fetch specification (fetching from the database). In this
>>> case, EOF will return the instance of Bar as expected.
>>
>> This is all starting to ring a bell with me. I think I've run into this
>> indirectly. From time to time I'll do something like this:
>>
>> folders = ERXQ.filtered(..., DocumentFolder.ORGANISATION.is
>> <http://documentfolder.organisation.is/>(document().organisation()));
>>
>> which doesn't produce the results I'm expecting, and I remember I need to do
>> this:
>>
>> folders = ERXQ.filtered(..., DocumentFolder.ORGANISATION.is
>> <http://documentfolder.organisation.is/>(document().organisation().localInstanceIn(someEditingContext)));
>>
>> If you drill down on ERXQ.filtered(), you eventually get to
>> EOQualifier.evaluateWithObject().
>>
>>> After some research, I found that I can extend the
>>> EOQualifier.ComparisonSupport class to evaluate all EOGenericRecord objects
>>> according to the ERXEOControlUtilities.eoEquals contract. I had a positive
>>> outcome after a preliminary experiment.
>>>
>>> I'd be interested to hear your views about this.
>>>
>>> - IMO, it is a bug. Do you agree?
>>
>> I agree. It's such an old, deep bug though that I've just internalised it
>> and now it's just normal EOF behaviour to me.
>>
>>> - Can you imagine any side effects of this fix?
>>
>> Not immediately. I assume the fix would have no effect on the kind of
>> localInstance() work-around that I presume we've all been using here. I'm
>> trying to contrive a scenario where you'd rely on the existing behaviour,
>> and I'm drawing a blank really.
>>
>>> - Since this change affects the in-memory evaluation of every type of EO,
>>> do you think it's appropriate to fix it on Wonder?
>>>
>>> I'm willing to contribute a pull request if that makes sense.
>>
>> Seems like a good idea to me. Do you want to at least create the PR and we
>> can have a look?
>>
>>
>> --
>> Paul Hoadley
>> https://logicsquad.net/ <https://logicsquad.net/>
>> https://www.linkedin.com/company/logic-squad/
>> <https://www.linkedin.com/company/logic-squad/>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden