db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: Derby regression/compatibility
Date Fri, 10 Feb 2006 21:23:30 GMT


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