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 <pa...@logicsquad.net> wrote: > > Hi Henrique, > > On 21 May 2019, at 08:22, Henrique Prange <hpra...@gmail.com > <mailto:hpra...@gmail.com>> 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(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/ >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
