db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Derby regression/compatibility
Date Fri, 10 Feb 2006 21:45:39 GMT
Great, this is exactly the kind of thing our Wiki page should itemize, 
saying this interface is private and can change without notice.

david

Satheesh Bandaram wrote:
> 
> Mike Matrigali wrote:
> 
> 
>>I believe we should also not be guaranteeing the system table
>>interfaces.  The supported interface should be jdbc metadata.
>>
> 
> Right... System schema could change between major/minor releases and we
> don't seem to be saying that explicitly in the section that talks about
> system schema in detail. Should I file a documentation issue?
> 
> Satheesh
> 
> 
>>David W. Van Couvering wrote:
>>
>>
>>>
>>>Kathey Marsden wrote:
>>>[snip]
>>>
>>>
>>>>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?
>>>
>>>
>>>
>>>I think of jar file names as an interface, but the others as signs of
>>>a regression in functionality.  And yes, we should identify the
>>>stability we guarantee for file names.  Other file names are the log
>>>file name ("derby.log"), the
>>>
>>>File formats are also interfaces, such as the message log file
>>>format, the database file format, and the transaction log file format.
>>>
>>>The other things you mention don't seem like interfaces but are
>>>measures for whether the product has regressed in some way.
>>>
>>>
>>>>Also, there are gray areas
>>>>.
>>>>- Changes to things like error codes, sqlstates and system tables. 
>>>
>>>
>>>
>>>These are interfaces, but since they're not documented, the should be
>>>considered "internal" and those no stability is guaranteed.
>>>
>>>
>>>>- Changes to make client match embedded for implementation defined
>>>>behaviour.
>>>
>>>
>>>
>>>Well, that's an interesting one.  The trick is as you do this, you
>>>may be changing the client interface in incompatible ways, even if
>>>you get better consistency across the two versions.
>>>
>>>
>>>>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.
>>>>
>>>
>>>Agreed
>>>
>>>
>>>>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 agree, but we should treat incompatibilities with different levels
>>>of severity depending upon our guarantees of stability we document
>>>(initially in the Wiki page, but ultimately I'd like to see this made
>>>available as part of our overall documentation).
>>>
>>>By the way, we at Sun have to provide this kind of documentation to
>>>our own internal architectural review committee.  We have to
>>>guarantee stability even if Derby can not, so that other projects can
>>>safely depend on us.  Having something like this for Derby would be
>>>very reassuring for *our* customers I can tell you that.
>>>
>>>David
>>>
>>>
>>>>>If this seems like a good list I'll create a wiki page.
>>>>>
>>>>>
>>>>>
>>>>
>>>>Thanks Dan!
>>>>
>>>>
>>
>>
>>
> 

Mime
View raw message