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
