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: Derby regression/compatibility
Date Fri, 10 Feb 2006 15:28:20 GMT
changing error codes and SQL States which are not correct in the current 
version of Derby should just be considered a bug fix.   You can always , 
if you feel it is really important, at a property for backward 
compatibility.

Daniel John Debrunner wrote:

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

Mime
View raw message