Jess Holle wrote: > Peter Becker wrote: >> I have heard of (and from) many people involved in the development of >> relational databases and/or the SQL standard who regret the introduction >> of NULL. Codd wanted it replaced with two distinct values, Date called >> them "a disaster". IIRC Jim Melton had some negative comments, too: >> http://www.se-radio.net/podcast/2009-06/episode-137-sql-jim-melton -- it >> has been a while that I listened to that episode. >> >> I don't think not only beginners would think of the following two >> selects as equivalent, but they are not: >> >> SELECT * FROM tableX; >> SELECT * FROM tableX WHERE x<=5 OR x>5; >> > That should come as no surprise to anyone who has used float or double > and has NaN's in the data. Which reminds me of another possible meaning of NULL: calculation error. The NaNs are the NULLs of the primitives. Same arguments apply, and yes: if you use some kind of NULL semantics in one type system, you want it in all. I personally think they are bad in any. > > Now something that really strikes me as odd is that some databases and > JDBC drivers go ape when you do > > preparedStatement.setDouble( bindIdx, doubleVar ); > > when doubleVar is NaN. > > Instead you have to do > > preparedStatement.setNull( bindIdx, dataType, typeName ); > > in this case, whereas you'd expect that setDouble() should just do the > right thing period. I kind of agree. Since NULL has ill-defined semantics, you could just live with the fact. I suspect the reasoning behind the behaviour you see is that it is not clear in general that the semantics of the SQL NULL and the Double.NaN match. The only truly safe option is to assume they don't and force you to go the long way, but in this case it seems overkill. At least a configuration option would be nice. > > Some JDBC drivers insist that you specify dataType even for trivial > cases (whereas typeName only needs to be specified for STRUCT types, > etc). This is allowed by the spec, but is really quite silly > considering the database knows the schema. For even more fun, some > databases/drivers will report the type of NCLOB columns as Types.OTHER > and then throw an exception if you turn around and pass this as the > dataType for setNull. It's enough to drive one absolutely batty. Isn't it always fun if specs are designed by committee and any conflict is resolved by defining optional behaviour :-) Consistency is for the weak of heart.
Peter --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
