You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Tore Halset <ha...@pvv.ntnu.no> on 2006/12/14 13:50:40 UTC
Re: Represesntation of database NULL as something else than Java
null pointer
On Dec 14, 2006, at 9:11 , Øyvind Harboe wrote:
> Could I implement my own "NeverNullString" datatype where I'm thinking
> that .toString() returns the either what Cayenne java.lang.String
> returns today or e.g. "" for the case where it represents a database
> null?
Or perhaps map java.lang.CharSequence and create a NullString that
implements it. You could then create an ExtendedType (perhaps
subclass CharType) that does what you want.
If your cayenne version if from before the fix of CAY-540 you may
have to register the type for each possible concreate class, just as
I did in the JTS-example.
You may get into some problems with the wrong (default) ExtendedType
get picked before your own, but it should be fixable.
- Tore.
Re: Represesntation of database NULL as something else than Java
null pointer
Posted by Tore Halset <ha...@pvv.ntnu.no>.
On Dec 14, 2006, at 14:09 , Øyvind Harboe wrote:
> Q++: Is it a good idea to use ExtendedType to represent database null
> as something else than Java null pointer?
I do not think it is a good idea in my project as I try to use "not
null" as much as possible. The places where I allow null, there
should be a good reason for it. It could be things like a status
message that are not inserted yet or a price that are not calculated.
For non-important fields like 'comment' I usually just insert "".
In a situation where you do not have control over the underlying
data, converting those null values to something usable seem to be a
good idea.
- Tore.
Re: Represesntation of database NULL as something else than Java null pointer
Posted by Øyvind Harboe <oy...@zylin.com>.
On 12/14/06, Tore Halset <ha...@pvv.ntnu.no> wrote:
> On Dec 14, 2006, at 9:11 , Øyvind Harboe wrote:
>
> > Could I implement my own "NeverNullString" datatype where I'm thinking
> > that .toString() returns the either what Cayenne java.lang.String
> > returns today or e.g. "" for the case where it represents a database
> > null?
>
> Or perhaps map java.lang.CharSequence and create a NullString that
> implements it. You could then create an ExtendedType (perhaps
> subclass CharType) that does what you want.
>
> If your cayenne version if from before the fix of CAY-540 you may
> have to register the type for each possible concreate class, just as
> I did in the JTS-example.
>
> You may get into some problems with the wrong (default) ExtendedType
> get picked before your own, but it should be fixable.
OK.
Q++: Is it a good idea to use ExtendedType to represent database null
as something else than Java null pointer?
--
Øyvind Harboe
http://www.zylin.com
Re: Re: Represesntation of database NULL as something else than Java null pointer
Posted by Øyvind Harboe <oy...@zylin.com>.
On 12/15/06, Michael Gentry <bl...@gmail.com> wrote:
> The NPEs from OGNL strings (like "foo.bar.name") are more of an OGNL
> issue than a Cayenne issue. At least in my opinion.
Actually we're trying to move away from OGNL because it breaks
refactoring. The fact that Spindle died didn't help. In some ways I'd
like Java to be *editable*(presented, but not embedded Java) from
within the HTML templates, instead of having OGNL expressions. While
not editing presented Java from within HTML templates, I'd like
something like OGNL expressions to be rendered.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=45423
With OGNL gone, the NPE problem remains and this puts the problem back
into Cayenne+Java land. Do a search on NPE & NullPointerException in
Eclipse's bugzilla. You'll be amazed how many hits you get. NPE is a
Java problem that Cayenne is being hit by, though I believe it would
be possible(although quite difficult) for Cayenne to come with some
NPE painkillers
We solved the Tapestry + OGNL + Cayenne NPE problem by introducing a
@SafeInsert component where we output an empty string for any
exceptions. Our underlying database is beyond repair and we get all
sorts of exceptions. We'll design a brand new database model + convert
from the old schema once our new app has been deployed to all
customers.
--
Øyvind Harboe
http://www.zylin.com
Re: Re: Represesntation of database NULL as something else than Java null pointer
Posted by Michael Gentry <bl...@gmail.com>.
The NPEs from OGNL strings (like "foo.bar.name") are more of an OGNL
issue than a Cayenne issue. At least in my opinion. I think the best
thing to do, especially with regards to Tapestry and OGNL and Cayenne,
is to add a cayenne: prefix extension to Tapestry (just like HLS added
a prop: prefix -- see
http://tapestryjava.blogspot.com/2006/11/improve-tapestry-performance-with.html
if not familiar with it). The cayenne: prefix would ignore nulls.
Like in your example of "foo.bar.name", if bar is null, the whole
expression is null. This has been on my personal to-do list for a
while. Maybe I should revisit it. Then most of the ognl: expressions
can go away and you won't need to write a lot of special null-handling
code. In my own project here, that special null-handling code can add
30-40% to the size of the page class. Nasty.
/dev/mrg
PS. I just started looking at that blog entry from HLS. Looks like he
has added path expressions to it since I last looked. It *may*
already handle nulls ... must investigate more.
On 12/14/06, Øyvind Harboe <oy...@zylin.com> wrote:
> On 12/14/06, Tore Halset <ha...@pvv.ntnu.no> wrote:
> > On Dec 14, 2006, at 9:11 , Øyvind Harboe wrote:
> >
> > > Could I implement my own "NeverNullString" datatype where I'm thinking
> > > that .toString() returns the either what Cayenne java.lang.String
> > > returns today or e.g. "" for the case where it represents a database
> > > null?
> >
> > Or perhaps map java.lang.CharSequence and create a NullString that
> > implements it. You could then create an ExtendedType (perhaps
> > subclass CharType) that does what you want.
>
> I messed around with this for a while and I've drawn some conclusions:
>
> - If I'm to use CharSequence instead of String's, then that needs to
> be in the application from day #1. It's testing hell trying to replace
> String w/anything but a subclass of string(which isn't possible since
> String is final).
> - As I'm using Tapestry, then if I return something to Tapestry that
> it interprets as an empty string, then it will set an empty string
> upon my Cayenne object during Form rewind. If I used an empty string
> to represent database null, my code would then make the mistake of
> changing the database value from database null to an empty string.
> - If it is OK from an application point of view to turn database null
> into empty strings as a side effect of Tapestry form rewind, then this
> approach seems fine and relatively straightforward.
> - ExtendedType can not deal with relationships and database null, and
> until I get rid of NPE(null pointer exceptions) w/relationships(ref.
> OGNL property strings foo.bar.name where bar might be null), I've only
> got half a solution. There have been other posts about relationships
> and NPE's in the past in Cayenne-user, but a robust solution is far
> from obvious.
>
>
> --
> Øyvind Harboe
> http://www.zylin.com
>
Re: Represesntation of database NULL as something else than Java null pointer
Posted by Øyvind Harboe <oy...@zylin.com>.
On 12/14/06, Tore Halset <ha...@pvv.ntnu.no> wrote:
> On Dec 14, 2006, at 9:11 , Øyvind Harboe wrote:
>
> > Could I implement my own "NeverNullString" datatype where I'm thinking
> > that .toString() returns the either what Cayenne java.lang.String
> > returns today or e.g. "" for the case where it represents a database
> > null?
>
> Or perhaps map java.lang.CharSequence and create a NullString that
> implements it. You could then create an ExtendedType (perhaps
> subclass CharType) that does what you want.
I messed around with this for a while and I've drawn some conclusions:
- If I'm to use CharSequence instead of String's, then that needs to
be in the application from day #1. It's testing hell trying to replace
String w/anything but a subclass of string(which isn't possible since
String is final).
- As I'm using Tapestry, then if I return something to Tapestry that
it interprets as an empty string, then it will set an empty string
upon my Cayenne object during Form rewind. If I used an empty string
to represent database null, my code would then make the mistake of
changing the database value from database null to an empty string.
- If it is OK from an application point of view to turn database null
into empty strings as a side effect of Tapestry form rewind, then this
approach seems fine and relatively straightforward.
- ExtendedType can not deal with relationships and database null, and
until I get rid of NPE(null pointer exceptions) w/relationships(ref.
OGNL property strings foo.bar.name where bar might be null), I've only
got half a solution. There have been other posts about relationships
and NPE's in the past in Cayenne-user, but a robust solution is far
from obvious.
--
Øyvind Harboe
http://www.zylin.com