Hi Henrique, On 21 May 2019, at 08:22, Henrique Prange <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(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://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
