db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [PRE-VOTE DISCUSSION] Compatibility rules and interface table
Date Thu, 22 Jun 2006 16:32:43 GMT


Rick Hillegas wrote:
> David Van Couvering wrote:
> 
>>
>>
>> Rick Hillegas wrote:
>>
>>> Hi David,
>>>
>>> I had a couple more comments on the compatibility commitments. 
>>> Cheers-Rick
>>>
>>>  - Changes to stored procedures: We will have to change column order if
>>>   we add Derby-specific columns to a metadata ResultSet and then a later
>>>   JDBC also adds more columns.
>>
>>
>> See Lance's email; OK to leave as is?
> 
> I thought the gist of Lance's response was this: It's ok to add 
> vendor-specific columns to metadata ResultSets. However, the leading 
> columns of the ResultSet must be the columns described in the JDBC spec 
> and those columns must appear in the specified order. After that the 
> order of vendor-specific columns doesn't matter. However, the names of 
> those vendor-specific columns do matter; those names are the stable 
> interface. I don't think the existing text on the compatibility webpage 
> captures this.

OK, I'll work on that

> 
>>
>>>
>>>  - Changes to Database Tables: We should be allowed to drop indexes
>>>   on System tables.
>>
>>
>> OK
>>
>>>
>>>  - Changes to Command Line Interfaces. I don't understand why error
>>>    message text can't be changed. This contradicts what is said
>>>    in the Interface Table below.
>>
>>
>> Hm, good point.  I suppose changing the error message text *is* an 
>> incompatible change, but given that the interface is private, it's OK 
>> to do it.  But it is a confusing message.  Any suggestions?  I can
>>
>> (a) remove error message text from the list of incompatible changes
>> (b) keep it, but clarify that this is a private interface
>> (c) make error message text a public interface
>>
>> My vote is for (a).  Anyone disagree?
> 
> That's my vote too, thanks.
> 

OK

>>
>>
>>>
>>>  - Other miscellaneous formats. I'm not clear on what these miscellaneou
>>>   files and strings are. For example, I'd like to make sure that 
>>> we're not enshrining
>>>   the current RUNTIMESTATISTICS output.
>>
>>
>> Again, I think this goes back to the same point.  It's not clear what 
>> the relationship is to the classification of an interface in the 
>> interfaces table and what it means to make an incompatible change.
>>
>> I think you're assuming incompatible changes can only apply to public 
>> interfaces, because it's really kind of moot/inapplicable for private 
>> interfaces.
>>
>> I think there's value in describing what it means to make an 
>> incompatible interface change, but I think the ultimate "truth" in 
>> terms of what we actually support in terms of interface stability 
>> across releases is described in the interfaces table.   I think some 
>> text in the "incompatible changes" section clarifying this would be 
>> helpful.
>>
>> Any thoughts?
> 
> I can see that Private Stable applies to the client/server api. These 
> apis should remain forward/backward compatible within a release family. 
> Do Private Stable interfaces turn up in other situations?

Yes, that's right.  I wonder if the database file format is also Private 
Stable.  I am still looking for some guidance in that area in terms of 
what are incompatible changes...

David

> 
>>
>>
>>>
>>>  - Interface table:
>>>
>>>    o Shouldn't the public client api be stable like the embedded api?
>>
>>
>> Yes
>>
>>>
>>>    o What is meant by "Defaults returned by DatabaseMetadata
>>>    methods"?
>>>
>>
>> I don't know, I think I put this in as feedback from someone else.  
>> Can anyone clarify?
>>
>>>    o I think that the format of RUNTIMESTATISTICS output is unstable.
>>>
>>
>> OK, anyone disagree?
>>
>> Thanks for your review, Rick!
>>
>> David
>>
>>>
>>> David Van Couvering wrote:
>>>
>>>> Hi, all.  I am thinking of setting up two separate votes based on 
>>>> the Wiki page at
>>>>
>>>> http://wiki.apache.org/db-derby/ForwardCompatibility
>>>>
>>>> The first one would be on our overall model/approach to making 
>>>> compatibility commitments, as described in the Wiki page.
>>>>
>>>> The second would be specifically for the interface table, targetted 
>>>> at the 10.2 release.
>>>>
>>>> The reason for separating these out is because, for each release, we 
>>>> should update the interface table and have a new vote; the overall 
>>>> model/approach does not need to be updated or voted on for each 
>>>> release.
>>>>
>>>> I would copy the appropriate text directly into the email for the 
>>>> vote, so that the thing we're voting on is a frozen snapshot, not a 
>>>> live document like the Wiki page.
>>>>
>>>> I'd like your feedback on this approach.  I'd also like to make sure 
>>>> there aren't any lingering issues with the Wiki page as it stands, 
>>>> before I go through the process of running a vote.
>>>>
>>>> Thanks,
>>>>
>>>> David
>>>
>>>
>>>
> 

Mime
View raw message