Re: Null values at end of sorted list (solved)
Re: Null values at end of sorted list (solved)
- Subject: Re: Null values at end of sorted list (solved)
- From: email@hidden
- Date: Tue, 12 Feb 2008 13:50:31 -0500
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@hidden> wrote
on 02-02-2008 01:31:15 AM:
> Hi Aaron,
>
> On 02/02/2008, at 8:35 AM, email@hidden 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden