db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Derby regression/compatibility
Date Fri, 10 Feb 2006 05:16:47 GMT
Kathey Marsden wrote:

> Daniel John Debrunner wrote:
>>In my view all public interfaces must remain compatible.
>>I believe these are the public interfaces, are there any others?
> [snip public api list]
>>- External behaviour defined by jar file manifest entries, e.g. OSGi
>>bundling now and auto-loading of JDBC driver in the future.
> Would sticky issues like ability to mix jar versions,   maintaining
> existing jar file names,  conforming to exisiting documented security
> permissions for  existing behaviour and ensuring jar file growth is
> commesurate with functionality improvement fall into this category?

Those are good to consider, maintaining the jar file names for sure. Jar
growth and performance in general are interesting since they are not
functional regressions. I think we all have the itch to have Derby used,
if we made it big and slow people wouldn't use it.

> Also, there are gray areas
> .
> - Changes to things like error codes, sqlstates and system tables. 
> - Changes to make client match embedded for implementation defined
> behaviour.
> I think here common sense and  sensitivity to users  has  to guide us as
> to when a change is acceptable or a lot of advance notification to the
> user community is needed.    Changing  SQLStates from null to something
> useful probably does not need much  advance notification to the user
> community, just documentation is sufficient.   Changing the error codes
> to match embedded probably requires significant prior notification.

Yes, depends. I would say ok to change any SQL state for a compilation
error, I can't see applications relying on specific SQLStates related to
a syntax error. But changing the error code for a deadlock or constraint
violation would impact applications.

> I think the 10.1 tests are a good way to try to understand the impact
> changes might have on existing applications.
> I've started to think maybe instead of strictly checking for behaviour
> depending on server version we should just change them all to work with
> 10.1, 10.2 and future versions like we ask our users  to do with their
> applications.  If nothing else,  it would make for good sensitivity
> training.

I think the running 10.1 tests against 10.2 in various forms has been a
good and useful exercise. I'm struggling thinking how to automate that,
given we did see sixty odd failures in some configurations.


View raw message