You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Daniel John Debrunner <dj...@apache.org> on 2006/02/10 05:20:14 UTC
Derby regression/compatibility
David W. Van Couvering wrote:
> I have also raised some concerns about what we mean by
> "compatibility" -- what interfaces must remain compatible? -- which have
> never really been resolved.
I thought this had been resolved the last time this was discussed, six
to eight months ago.
In my view all public interfaces must remain compatible.
I believe these are the public interfaces, are there any others?
- Derby's SQL language support
- Derby's JDBC support
- Derby's embedded published/public api classes
(defined by the published api javadoc target)
http://db.apache.org/derby/docs/10.1/publishedapi/
- Derby's network api - DRDA protocol support
- External behaviour defined by jar file manifest entries, e.g. OSGi
bundling now and auto-loading of JDBC driver in the future.
- Platform support
* J2SE 1.3/1.4/1.5 support
* J2ME/CDC/Foundation support
* Pure Java to enable run-anywhere
Derby's versioning of its on-disk database format is described here:
http://db.apache.org/derby/papers/versionupgrade.html
There will be occasions where the Derby community does introduce
regressions or what might be considered regressions by some. Any such
item should be a deliberate choice by the community not by accident. I
think Kathey was thinking of writing up what might make a regression ok.
Examples are:
Disabling getXXXStream to be called twice on the same column in the
same row in 10.2. Previously 10.1 and 10.1 allowed this but returned the
incorrect data. It seems a reasonable choice as it stops incorrect
behaviour and is in-line with the JDBC spec.
Dropping support of JDK 1.3/JDBC2.1. Technically a regression but
it seems unlikely that by the time the community does this that there
will be any demand for JDK 1.3. (We've voted that it's ok to do this in
10.3, but someone has to scratch that itch)
I also assume that an api must be providing useful and reasonable
functionality for an application. For example changing a public api from
throwing a not-implemented exception to implementing the functionality
is not a regression. :-) Applications that are relying on broken
behaviour or unreasonable un-documented behaviour should not stand in
the way of improving Derby.
If this seems like a good list I'll create a wiki page.
Dan.
Re: Derby regression/compatibility
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Thanks, Dan. I'll take a look at this when I get back from paternity leave.
David
Daniel John Debrunner wrote:
> Daniel John Debrunner wrote:
>
>
>>David W. Van Couvering wrote:
>>
>>
>>
>>>I have also raised some concerns about what we mean by
>>>"compatibility" -- what interfaces must remain compatible? -- which have
>>>never really been resolved.
>>
>>
>>I thought this had been resolved the last time this was discussed, six
>>to eight months ago.
>>
>>In my view all public interfaces must remain compatible.
>
>
> [snip]
>
>
>>If this seems like a good list I'll create a wiki page.
>
>
> I've created the initial version of this page:
>
> http://wiki.apache.org/db-derby/ForwardCompatibility
>
> I tried to capture a few points from the follow up e-mails, mainly
> anything that clearly was part of the public api. Please feel free to
> modify the page if I missed anything.
>
> Dan.
>
Re: Derby regression/compatibility
Posted by Daniel John Debrunner <dj...@apache.org>.
Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
>
>
>> I have also raised some concerns about what we mean by
>>"compatibility" -- what interfaces must remain compatible? -- which have
>>never really been resolved.
>
>
> I thought this had been resolved the last time this was discussed, six
> to eight months ago.
>
> In my view all public interfaces must remain compatible.
[snip]
> If this seems like a good list I'll create a wiki page.
I've created the initial version of this page:
http://wiki.apache.org/db-derby/ForwardCompatibility
I tried to capture a few points from the follow up e-mails, mainly
anything that clearly was part of the public api. Please feel free to
modify the page if I missed anything.
Dan.
Re: Derby regression/compatibility
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I agree that these tests should not be logged as regression test
failures (until the compatibility suite is part of the nightly
regression test). That is not saying they are not important, it
is just not what the regression test component is trying to track.
David W. Van Couvering wrote:
> Thanks, Dan, a Wiki page would be great. I would suggest a table of
> interface and the level of stability guaranteed for each of them
> (basically "stable" or "stability guaranteed between minor releases
> only" or "unstable").
>
> The issue I have with the otherwise excellent set of compatibility tests
> Raman ran was that some of the "incompatibilities" (unless I am
> mistaken) appear to be for interfaces that are not (currently)
> guaranteed to be stable, in particular the output format of ij. Although
> I think it's good to note that these differences exist by logging a
> JIRA, I don't think they should be categorized as a failure in
> regression tests.
>
> David
>
> Daniel John Debrunner wrote:
>
>> David W. Van Couvering wrote:
>>
>>
>>> I have also raised some concerns about what we mean by
>>> "compatibility" -- what interfaces must remain compatible? -- which have
>>> never really been resolved.
>>
>>
>>
>> I thought this had been resolved the last time this was discussed, six
>> to eight months ago.
>>
>> In my view all public interfaces must remain compatible.
>>
>> I believe these are the public interfaces, are there any others?
>>
>> - Derby's SQL language support
>>
>> - Derby's JDBC support
>>
>> - Derby's embedded published/public api classes
>> (defined by the published api javadoc target)
>> http://db.apache.org/derby/docs/10.1/publishedapi/
>>
>> - Derby's network api - DRDA protocol support
>>
>> - External behaviour defined by jar file manifest entries, e.g. OSGi
>> bundling now and auto-loading of JDBC driver in the future.
>>
>> - Platform support
>> * J2SE 1.3/1.4/1.5 support
>> * J2ME/CDC/Foundation support
>> * Pure Java to enable run-anywhere
>>
>> Derby's versioning of its on-disk database format is described here:
>> http://db.apache.org/derby/papers/versionupgrade.html
>>
>> There will be occasions where the Derby community does introduce
>> regressions or what might be considered regressions by some. Any such
>> item should be a deliberate choice by the community not by accident. I
>> think Kathey was thinking of writing up what might make a regression ok.
>> Examples are:
>>
>> Disabling getXXXStream to be called twice on the same column in the
>> same row in 10.2. Previously 10.1 and 10.1 allowed this but returned the
>> incorrect data. It seems a reasonable choice as it stops incorrect
>> behaviour and is in-line with the JDBC spec.
>>
>> Dropping support of JDK 1.3/JDBC2.1. Technically a regression but
>> it seems unlikely that by the time the community does this that there
>> will be any demand for JDK 1.3. (We've voted that it's ok to do this in
>> 10.3, but someone has to scratch that itch)
>>
>> I also assume that an api must be providing useful and reasonable
>> functionality for an application. For example changing a public api from
>> throwing a not-implemented exception to implementing the functionality
>> is not a regression. :-) Applications that are relying on broken
>> behaviour or unreasonable un-documented behaviour should not stand in
>> the way of improving Derby.
>>
>> If this seems like a good list I'll create a wiki page.
>>
>> Dan.
>>
>>
Re: Derby regression/compatibility
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
> Thanks, Dan, a Wiki page would be great. I would suggest a table of
> interface and the level of stability guaranteed for each of them
> (basically "stable" or "stability guaranteed between minor releases
> only" or "unstable").
>
> The issue I have with the otherwise excellent set of compatibility
> tests Raman ran was that some of the "incompatibilities" (unless I am
> mistaken) appear to be for interfaces that are not (currently)
> guaranteed to be stable, in particular the output format of ij.
> Although I think it's good to note that these differences exist by
> logging a JIRA, I don't think they should be categorized as a failure
> in regression tests.
>
DERBY-880 was originally filed as a regression because the test was
passing and seemingly getting valid results with 10.1. Running it with
10.2 caused this error and the test to fail miserably, so at first
glance looked like a serious regression. Dan pointed out that the test
probably needs to be changed to not retrieve the lob twice and then it
will be ok again, but of course it would be good to verify that sooner
rather than later.
I think it is ok to take it out of the regression test failure
category. I'll go ahead and do so.
Kathey
Re: Derby regression/compatibility
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Thanks, Dan, a Wiki page would be great. I would suggest a table of
interface and the level of stability guaranteed for each of them
(basically "stable" or "stability guaranteed between minor releases
only" or "unstable").
The issue I have with the otherwise excellent set of compatibility tests
Raman ran was that some of the "incompatibilities" (unless I am
mistaken) appear to be for interfaces that are not (currently)
guaranteed to be stable, in particular the output format of ij.
Although I think it's good to note that these differences exist by
logging a JIRA, I don't think they should be categorized as a failure in
regression tests.
David
Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
>
>
>> I have also raised some concerns about what we mean by
>>"compatibility" -- what interfaces must remain compatible? -- which have
>>never really been resolved.
>
>
> I thought this had been resolved the last time this was discussed, six
> to eight months ago.
>
> In my view all public interfaces must remain compatible.
>
> I believe these are the public interfaces, are there any others?
>
> - Derby's SQL language support
>
> - Derby's JDBC support
>
> - Derby's embedded published/public api classes
> (defined by the published api javadoc target)
> http://db.apache.org/derby/docs/10.1/publishedapi/
>
> - Derby's network api - DRDA protocol support
>
> - External behaviour defined by jar file manifest entries, e.g. OSGi
> bundling now and auto-loading of JDBC driver in the future.
>
> - Platform support
> * J2SE 1.3/1.4/1.5 support
> * J2ME/CDC/Foundation support
> * Pure Java to enable run-anywhere
>
> Derby's versioning of its on-disk database format is described here:
> http://db.apache.org/derby/papers/versionupgrade.html
>
> There will be occasions where the Derby community does introduce
> regressions or what might be considered regressions by some. Any such
> item should be a deliberate choice by the community not by accident. I
> think Kathey was thinking of writing up what might make a regression ok.
> Examples are:
>
> Disabling getXXXStream to be called twice on the same column in the
> same row in 10.2. Previously 10.1 and 10.1 allowed this but returned the
> incorrect data. It seems a reasonable choice as it stops incorrect
> behaviour and is in-line with the JDBC spec.
>
> Dropping support of JDK 1.3/JDBC2.1. Technically a regression but
> it seems unlikely that by the time the community does this that there
> will be any demand for JDK 1.3. (We've voted that it's ok to do this in
> 10.3, but someone has to scratch that itch)
>
> I also assume that an api must be providing useful and reasonable
> functionality for an application. For example changing a public api from
> throwing a not-implemented exception to implementing the functionality
> is not a regression. :-) Applications that are relying on broken
> behaviour or unreasonable un-documented behaviour should not stand in
> the way of improving Derby.
>
> If this seems like a good list I'll create a wiki page.
>
> Dan.
>
>
Re: Derby regression/compatibility
Posted by "Lance J. Andersen" <La...@Sun.COM>.
changing error codes and SQL States which are not correct in the current
version of Derby should just be considered a bug fix. You can always ,
if you feel it is really important, at a property for backward
compatibility.
Daniel John Debrunner wrote:
>Kathey Marsden wrote:
>
>
>
>>Daniel John Debrunner wrote:
>>
>>
>>
>>
>>>In my view all public interfaces must remain compatible.
>>>
>>>I believe these are the public interfaces, are there any others?
>>>
>>>
>>>
>>>
>>[snip public api list]
>>
>>
>>
>>
>>>- External behaviour defined by jar file manifest entries, e.g. OSGi
>>>bundling now and auto-loading of JDBC driver in the future.
>>>
>>>
>>>
>>>
>>>
>>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?
>>
>>
>
>Those are good to consider, maintaining the jar file names for sure. Jar
>growth and performance in general are interesting since they are not
>functional regressions. I think we all have the itch to have Derby used,
>if we made it big and slow people wouldn't use it.
>
>
>
>
>>Also, there are gray areas
>>.
>>- Changes to things like error codes, sqlstates and system tables.
>>- Changes to make client match embedded for implementation defined
>>behaviour.
>>
>>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.
>>
>>
>
>Yes, depends. I would say ok to change any SQL state for a compilation
>error, I can't see applications relying on specific SQLStates related to
>a syntax error. But changing the error code for a deadlock or constraint
>violation would impact applications.
>
>
>
>>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 think the running 10.1 tests against 10.2 in various forms has been a
>good and useful exercise. I'm struggling thinking how to automate that,
>given we did see sixty odd failures in some configurations.
>
>
>Dan.
>
>
Re: Derby regression/compatibility
Posted by Daniel John Debrunner <dj...@apache.org>.
Kathey Marsden wrote:
> Daniel John Debrunner wrote:
>
>
>>In my view all public interfaces must remain compatible.
>>
>>I believe these are the public interfaces, are there any others?
>>
>>
>
> [snip public api list]
>
>
>>- External behaviour defined by jar file manifest entries, e.g. OSGi
>>bundling now and auto-loading of JDBC driver in the future.
>>
>>
>>
>
> 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?
Those are good to consider, maintaining the jar file names for sure. Jar
growth and performance in general are interesting since they are not
functional regressions. I think we all have the itch to have Derby used,
if we made it big and slow people wouldn't use it.
>
> Also, there are gray areas
> .
> - Changes to things like error codes, sqlstates and system tables.
> - Changes to make client match embedded for implementation defined
> behaviour.
>
> 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.
Yes, depends. I would say ok to change any SQL state for a compilation
error, I can't see applications relying on specific SQLStates related to
a syntax error. But changing the error code for a deadlock or constraint
violation would impact applications.
> 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 think the running 10.1 tests against 10.2 in various forms has been a
good and useful exercise. I'm struggling thinking how to automate that,
given we did see sixty odd failures in some configurations.
Dan.
Re: Derby regression/compatibility
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
> Hi, Kathey. Sun is very very committed to compatibility; Solaris, for
> example, has been binary compatible since release 2.0 some umpteen
> years ago. Not only is this a key benefit to customers, I believe it
> is what has made it possible for Solaris to even make it out the door
> on a regular, reliable schedule, because it has so many interdependent
> components. If compatibility was broken willy nilly we'd have three
> months of "the build is *still* broken" at every release cycle :)
>
> I can't really do a link for our internal docs, as our internal folks
> require these "interface contracts" to be committed to an internal
> repository. But I would be very happy to work with you all on the
> Wiki page describing our interfaces and the level of stability the
> Derby team is committed to for each interface. It would help with a
> lot of these discussions and help keep awareness of this high within
> the community.
>
Actually I was thinking the other way around. Make up documents for
"interface contracts" for Derby which can be debated and accepted, then
link or cut and paste that into whatever internal format/repository
format you have. Making sure the committment starts in the Derby
community is the only way to guarantee it to your internal customers in
an open source environment.
Anyway, the Wiki is a good start. I do plan to make a page for 10.2 of
changes that might affect existing applications. (We actually have
quite a few) to try to help the user community prepare. I am behind on
that like everything else #:(. At least it sounds like the days the
massive regression marketted as an "edge case" like, "Let's break all
the existing clients in the world for the sake of a pretty product id"
are over and life as the Lorax will be easier for me.
Kathey
Re: Derby regression/compatibility
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Hi, Kathey. Sun is very very committed to compatibility; Solaris, for
example, has been binary compatible since release 2.0 some umpteen years
ago. Not only is this a key benefit to customers, I believe it is what
has made it possible for Solaris to even make it out the door on a
regular, reliable schedule, because it has so many interdependent
components. If compatibility was broken willy nilly we'd have three
months of "the build is *still* broken" at every release cycle :)
I can't really do a link for our internal docs, as our internal folks
require these "interface contracts" to be committed to an internal
repository. But I would be very happy to work with you all on the Wiki
page describing our interfaces and the level of stability the Derby team
is committed to for each interface. It would help with a lot of these
discussions and help keep awareness of this high within the community.
David
Kathey Marsden wrote:
> David W. Van Couvering wrote:
>
>
>>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.
>>
>
>
> Well this is a huge ray of hope for the installed user base! It is
> wonderful that that you have these requirements and are working on
> such documentation. I am also thrilled to hear Sun plans this kind
> of commitment to stability moving forward.
> I hope your internal documentation can come in the form of links to
> documentation you have contributed to the project.
>
> Thanks
>
> Kathey
>
>
Re: Derby regression/compatibility
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
>
> 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.
>
Well this is a huge ray of hope for the installed user base! It is
wonderful that that you have these requirements and are working on
such documentation. I am also thrilled to hear Sun plans this kind
of commitment to stability moving forward.
I hope your internal documentation can come in the form of links to
documentation you have contributed to the project.
Thanks
Kathey
Re: Derby regression/compatibility
Posted by Daniel John Debrunner <dj...@apache.org>.
Satheesh Bandaram wrote:
>
> Mike Matrigali wrote:
>
>
>>I believe we should also not be guaranteeing the system table
>>interfaces. The supported interface should be jdbc metadata.
>>
>
> Right... System schema could change between major/minor releases and we
> don't seem to be saying that explicitly in the section that talks about
> system schema in detail. Should I file a documentation issue?
Are you saying that the system tables could change in a way that would
break existing queries to break? Or do you mean items like additional
system tables, additional columns and/or additional values in existing
columns?
Dan.
Re: Derby regression/compatibility
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Great, this is exactly the kind of thing our Wiki page should itemize,
saying this interface is private and can change without notice.
david
Satheesh Bandaram wrote:
>
> Mike Matrigali wrote:
>
>
>>I believe we should also not be guaranteeing the system table
>>interfaces. The supported interface should be jdbc metadata.
>>
>
> Right... System schema could change between major/minor releases and we
> don't seem to be saying that explicitly in the section that talks about
> system schema in detail. Should I file a documentation issue?
>
> Satheesh
>
>
>>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!
>>>>
>>>>
>>
>>
>>
>
Re: Derby regression/compatibility
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Mike Matrigali wrote:
> I believe we should also not be guaranteeing the system table
> interfaces. The supported interface should be jdbc metadata.
>
Right... System schema could change between major/minor releases and we
don't seem to be saying that explicitly in the section that talks about
system schema in detail. Should I file a documentation issue?
Satheesh
> 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!
>>>
>>>
>
>
>
Re: Derby regression/compatibility
Posted by Mike Matrigali <mi...@sbcglobal.net>.
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!
>>
>>
Re: Derby regression/compatibility
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
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!
>
>
Re: Derby regression/compatibility
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner wrote:
>In my view all public interfaces must remain compatible.
>
>I believe these are the public interfaces, are there any others?
>
>
[snip public api list]
>- External behaviour defined by jar file manifest entries, e.g. OSGi
>bundling now and auto-loading of JDBC driver in the future.
>
>
>
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?
Also, there are gray areas
.
- Changes to things like error codes, sqlstates and system tables.
- Changes to make client match embedded for implementation defined
behaviour.
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.
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.
>If this seems like a good list I'll create a wiki page.
>
>
>
Thanks Dan!