EOF also has the EONull class. Well, for Java, I think it is
EONullValue, but the same idea. Not sure if something like that would
be useful to have around.
For me personally, I prefer nulls to just go away. If I want to
compare if something is null, I can do a comparison. Otherwise, I
like operations on null to give me null. This is my Objective-C half
speaking. Gets me into trouble in Java, because it throws. Last time
I looked at the OGNL null handler, you had to provide one for every
single class that you wanted to catch nulls on, which made it
inconvenient (I wanted it on every class).
In my Tapestry app, I have lots of cover methods that check each
relationship for null along the path because OGNL would hurl if I were
missing a relationship (so I really couldn't use paths in OGNL). I
found this to be messy and annoying -- especially since I was just
displaying data in a read-only table. If I'm missing data, I didn't
want to show anything. I never did get around to writing that
cayenne: binding (to use CayenneDataObject's readNestedProperty). I
think I've officially digressed ...
*Carrier Lost*
On 12/1/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
> > In terms of utility to the developer, the current behaviour is
> > problematic. It means that for every relation which could possibly
> > be NULL, then we cannot use the Cayenne sorting functionality. We
> > might have 100,000 records and one NULL value, but we then cannot
> > sort.
>
> Yes. But this is a question about correctness and predictability of
> either behavior, so "1 out of 100,000" case is not really an argument
> here. It either works one way or another. Also note that whatever
> change we implement will affect not only sorting, but also expression
> evaluation (==, !=, etc).
>
> The more I think about it, the more I am against entirely abandoning
> the correct behavior (and allowing for null related objects to be
> treated the same as null object properties). So this leaves us with
> the option to make it configurable. The problem with OGNL null
> handler (and everything else OGNL) is its static nature... If we are
> to implement something like that, it will have to be contextual, set
> per Expression or Ordering instance. And I agree that null handler is
> probably an overkill - a boolean flag should probably be enough.
>
> Andrus
>
>
> On Dec 1, 2006, at 3:08 PM, Aristedes Maniatis wrote:
> > On 01/12/2006, at 10:46 PM, Andrus Adamchik wrote:
> >
> >> I am taking this discussion to cayenne-dev from Jira. Essentially
> >> this is about whether Ordering (and Expression I guess) should
> >> throw on nulls in the middle of the property path (like OGNL does)
> >> or return NULL (like WebObjects does).
> >>
> >> I can think of one problem with returning nulls: we won't be
> >> comparing apples to apples ("painting.artist == null" is not the
> >> same as "painting.artist.name == null"). But of course it is a
> >> nice shortcut...
> >
> > In terms of utility to the developer, the current behaviour is
> > problematic. It means that for every relation which could possibly
> > be NULL, then we cannot use the Cayenne sorting functionality. We
> > might have 100,000 records and one NULL value, but we then cannot
> > sort.
> >
> >
> > It seems that even OGNL allows NullPointerExceptions to be
> > overridden. http://www.ognl.org/2.6.9/Documentation/html/
> > DeveloperGuide/nullHandler.html
> >
> > Perhaps the equivalent of this OGNL idea is to be able to map
> > "painting.artist == null" to "No linked artist" or some other
> > arbitrary value and "painting.artist.name == null" to "No name".
> > Then they might be sorted alphabetically under "N". But personally
> > I think this is overkill and not really needed. Grouping them all
> > as null, without distinguishing the type of null, would be simpler.
> >
> >
> > Ari Maniatis
> >
> >
> > -------------------------->
> > ish
> > http://www.ish.com.au
> > Level 1, 30 Wilson Street Newtown 2042 Australia
> > phone +61 2 9550 5001 fax +61 2 9550 4001
> > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
This archive was generated by hypermail 2.0.0 : Fri Dec 01 2006 - 08:43:25 EST