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
