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: [PRE-VOTE DISCUSSION] Compatibility rules and interface table
Date Wed, 21 Jun 2006 20:17:02 GMT
hi guys

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.
Any vendor specific columns added should only be accessed via column 
name and you should document that.

we did clarify this in the JDBC spec
>
>  - Changes to Database Tables: We should be allowed to drop indexes
>   on System tables.
>
>  - 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.
>
>  - 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.
>
>  - Interface table:
>
>    o Shouldn't the public client api be stable like the embedded api?
>
>    o What is meant by "Defaults returned by DatabaseMetadata
>    methods"?
>
>    o I think that the format of RUNTIMESTATISTICS output is unstable.
>
>
> 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