Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43ECCC1B.9030104@sbcglobal.net>
Date: Fri, 10 Feb 2006 09:23:39 -0800
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Derby regression/compatibility
References: <43EBC409.9080106@sbcglobal.net> <43EBD2FE.3040407@sun.com>
 <43EBD6A7.9010107@sbcglobal.net> <43EBEE07.9090008@sun.com>
 <43EC147E.7010209@apache.org> <43EC1CC4.2030207@sbcglobal.net>
 <43EC213F.3070503@sun.com>
In-Reply-To: <43EC213F.3070503@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I would argue that the log file format and data file format are not
interfaces we guarantee.  What we guarantee is that on upgrade the
new database will be able to access the data in those files.  There
is no support for user direct access to those files.

I believe we should also not be guaranteeing the system table
interfaces.  The supported interface should be jdbc metadata.

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