db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Not forgiving non-portable applications - Was: Re: behavior of Statement.getGeneratedKeys()
Date Fri, 14 Jul 2006 16:40:26 GMT
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.

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.


View raw message