Hello Everyone, We solved the problem.
Thanks to all of you who read, pondered, and lent a helping hand with this issue. It's appreciated. There was nothing wrong with our custom comparison support or how we were initializing it and using it. The problem rests in how we are using WOnder and that our custom comparison support was getting clobbered with a different comparison support for Strings from Project WOnder. When an NSKeyValueCoding.Null object was compared to a java String object, K2Sort would get confused depending on which object was on the left hand side of the comparison. The "null" object used our CXNullsAtEndCompirsonSupport and the Strings were using a custom localized ComparisonSupport from Project WOnder. This results in the two objects being both "bigger" and "smaller" than each other at the same time and making K2Sort get in a pickle (like jump off the edge of an array of sorted values). When I said, "everything worked fine until I did an ec.saveChanges()" I was incorrect. I should have said "everything worked fine until I navigated to part of the app that lazily initialized the ERXLocalizer". See what happened? Our code worked with any "Object" but ERXLocalizer invoked a comparison support on something more specific, a "String". For now our solution is to initialize ERXLocalizer.currentLocalizer at Application startup and then set our comparison support on both "Object.class" and "String.class". This clobbers the WOnder goodness but we aren't relying on those features at the moment. A better solution would be to contribute back to WOnder and allow a property to be set of how we want nulls handled, "at the end" or "at the beginning" of an ascending sort. But we haven't migrated to Eclipse yet and aren't set up to submit patches. Thanks, -- Aaron Lachlan Deck <[EMAIL PROTECTED]> wrote on 02-02-2008 01:31:15 AM: > Hi Aaron, > > On 02/02/2008, at 8:35 AM, [EMAIL PROTECTED] wrote: > > > I'm not sure what your code was fixing though. I thought that > > "Object.class" was the root of everything and would be a catch all. > > Actually, yes my bad. I scanned the code too quickly. > > So is your code even getting called during fetches from the db? > > Alternative... subclass EODatabaseContext (e.g., overriding > objectsWithFetchSpecification( EOFetchSpecification fetchSpec, > EOEditingContext context ). This is what I'm doing for ensuring a > default sort for certain entities prior to calling super. Some > alternative to that might work, or delegate method. At least you > might be able to trace what's getting called. > > Have you also looked at EOQualifier.Comparison[Support]? It talks a > little about Java Client, however these might have a part to play in > normal server-side stuff anyway. > > with regards, > -- > > Lachlan Deck > > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
