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
