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 > <webobjects-dev@lists.apple.com> 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: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 > > >> On May 31, 2019, at 2:37 PM, Henrique Prange via Webobjects-dev >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> 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 <pa...@logicsquad.net >>> <mailto: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 >>> <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 (Webobjects-dev@lists.apple.com >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com >> <https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com> >> >> This email sent to aa...@chatnbike.com <mailto:aa...@chatnbike.com> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com > <mailto:Webobjects-dev@lists.apple.com>) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com > <https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com> > > This email sent to hill.ch...@gmail.com <mailto:hill.ch...@gmail.com>
_______________________________________________ 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
