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: Chuck Hill via Webobjects-dev <email@hidden>
- Date: Fri, 31 May 2019 19:03:00 -0700
The other thing to consider is that comparing the EOGlobalID means they are the
same object, but that does not meant the two objects are the same — if either
EC has uncommitted changes. Unless you are using READ UNCOMMITTED that is not
a case you will encounter in the database. It does not look significant in
this case, but could be in others.
Chuck
> On May 31, 2019, at 6:09 PM, Aaron Rosenzweig via Webobjects-dev
> <email@hidden> wrote:
>
> 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 <mailto: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
>> <mailto:email@hidden>)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden <mailto:email@hidden>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden
> <mailto:email@hidden>)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden <mailto: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