db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: Not forgiving non-portable applications - Was: Re: behavior of Statement.getGeneratedKeys()
Date Fri, 14 Jul 2006 17:11:48 GMT


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.
>
>   

Mime
View raw message