Hey guys, 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(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. 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. 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? - Can you imagine any side effects of this fix? - 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. Cheers, HP
_______________________________________________ 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
