Re: Not forgiving non-portable applications - Was: Re: behavior of Statement.getGeneratedKeys()

[Lance J. Andersen]

Daniel John Debrunner wrote: Kathey Marsden wrote: Another similar case is DERBY-1501 where it would be nice if Derby were more forgiving of non-portable apps. Of course in both of those other cases we would just be adding to existing support, not changing existing behavior and `there is a risk to apps that develop on Derby and expect to be able to move without changes to another db. We need to be careful about being forgiving to non-portable applications, part of Derby's charter is to allow applications to easily migrate from Derby to other databases that follow the same standards. With 1501 the JDBC spec says the type must be known (I think it's a bug in the *draft* spec for the type to be ignored), that's the portable behaviour, ignoring the type not only leads to non-portable applications but also inconsistencies in derby. E.g. a NULL defined as a DATE could used for a BLOB value through JDBC, but not using SQL. Can u help me here as to what it the bug you are referring to?  too many emails today to see the forest through the trees. -lance As extreme examples, should Derby be forgiving of non-portable MySQL applications that insert NULLs into non-nullable columns, or SQLLite applications that insert DATE values into INTEGER columns? Following the standard closely (and helping clean-up the JDBC standard) provides the clearest direction on these issues. Dan.