Re: Compatibility guarantees for SQL states and messages
Hi David, There's clearly a compatibility issue here. Reasonable applications do look at the SQLStates of caught exceptions. However, I think our guidelines let us fix incorrect SQLStates--including making the Network and Embedded clients agree. I would recommend listing SQLState changes in the Release Notes. Regards, -Rick David W. Van Couvering wrote: Hi, all. I looked at the listing of Derby's public APIs (see http://wiki.apache.org/db-derby/ForwardCompatibility), and it mentions Derby's JDBC support. I need to delve in a little deeper. Are we guaranteeing compatibility for the SQL States? For the 10.2 release, is it OK for me to change the SQL State of an existing message, or do I need to keep it the same across minor releases? What about the text of messages? I noticed that we changed these between 10.0 and 10.1, so I'm assuming these can change across minor release boundaries. What about across patch releases? Thanks, David
Re: Compatibility guarantees for SQL states and messages
David W. Van Couvering wrote: Hi, all. I looked at the listing of Derby's public APIs (see http://wiki.apache.org/db-derby/ForwardCompatibility), and it mentions Derby's JDBC support. I need to delve in a little deeper. Are we guaranteeing compatibility for the SQL States? For the 10.2 release, is it OK for me to change the SQL State of an existing message, or do I need to keep it the same across minor releases? I don't think SQLStates are defined by the JDBC Standard but rather the SQL Standard. To that extent they should be compliant and match embedded where possible. SQLStates are documented but we have this caveat for client: http://db.apache.org/derby/docs/dev/ref/rrefexcept71493.html The following tables list /SQLStates/ for exceptions. Exceptions that begin with an /X/ are specific to Derby. Note that some SQLStates specific to the network client might change in future releases. We also voted early to make client match embedded where possible and that is in the documentation here. http://db.apache.org/derby/docs/dev/adminguide/cadminappsclientdiffs.html. I think that even within these guidelines early notification and buy in from the user community is key, so should be posted on the user list. and a Wiki page provided with information on how to write applications that will work on both old and new versions. But I think it is ok to change the SQLStates on client to: 1) Match the standard. 2) Match embedded. 3) Create a new SQLState instead of having a null SQLState for SQLExceptions that are specific to client. but not ok to : 1) Change client from some existing SQLState to another SQLState that is neither compliant nor matches embedded. I think message text can be changed, but the null SQLStates and message text are an interesting case, because before that was the only way for an app to check the error. I think some of our testing code does this. Kathey
Re: Compatibility guarantees for SQL states and messages
Thanks, Kathey. What if I find an existing SQLState in the embedded code that uses a Derby-specific SQL State but which I think really should be a standard SQL state? For example, I think 42X89 (Types ''{0}'' and ''{1}'' are not type compatible. Neither type is assignable to the other type.) really is a case of the standard SQL State 22005 - error in assignment So the question is, using the taxonomy described in http://wiki.apache.org/db-derby/ForwardCompatibility should SQL States be Stable or Unstable? If they are Stable, then I can't fix this until 11.0, and I just need to log a bug for now. If they are Unstable, I can fix this in 10.2. I think really since our SQL States are documented, and we don't really think of them as experimental or transitional, then they should be considered Stable, and I really can't change an existing SQL State in a minor release. But when adding a new SQL state to the client, which takes priority: being consistent with the SQL state in embedded driver which is non-compliant with the standard, or being consistent with the SQL standard? I would vote for being consistent with the standard, and explain that the inconsistency is due to a bug in the embedded driver which will be fixed in the next major release. Thanks, David Kathey Marsden wrote: David W. Van Couvering wrote: Hi, all. I looked at the listing of Derby's public APIs (see http://wiki.apache.org/db-derby/ForwardCompatibility), and it mentions Derby's JDBC support. I need to delve in a little deeper. Are we guaranteeing compatibility for the SQL States? For the 10.2 release, is it OK for me to change the SQL State of an existing message, or do I need to keep it the same across minor releases? I don't think SQLStates are defined by the JDBC Standard but rather the SQL Standard. To that extent they should be compliant and match embedded where possible. SQLStates are documented but we have this caveat for client: http://db.apache.org/derby/docs/dev/ref/rrefexcept71493.html The following tables list /SQLStates/ for exceptions. Exceptions that begin with an /X/ are specific to Derby. Note that some SQLStates specific to the network client might change in future releases. We also voted early to make client match embedded where possible and that is in the documentation here. http://db.apache.org/derby/docs/dev/adminguide/cadminappsclientdiffs.html. I think that even within these guidelines early notification and buy in from the user community is key, so should be posted on the user list. and a Wiki page provided with information on how to write applications that will work on both old and new versions. But I think it is ok to change the SQLStates on client to: 1) Match the standard. 2) Match embedded. 3) Create a new SQLState instead of having a null SQLState for SQLExceptions that are specific to client. but not ok to : 1) Change client from some existing SQLState to another SQLState that is neither compliant nor matches embedded. I think message text can be changed, but the null SQLStates and message text are an interesting case, because before that was the only way for an app to check the error. I think some of our testing code does this. Kathey
Re: Compatibility guarantees for SQL states and messages
If it is deemed to be the wrong SQLState, then you should fix it. My experience is JDBC developers are more focused on the Exception and if they check further they often dig into the vendor error. This was a reason we added the SQLException sub classes to help aid in better portability. If you have not bought a copy of the SQL Standard you really do not know what this means (SQLState) anyways. my .02 David W. Van Couvering wrote: Thanks, Kathey. What if I find an existing SQLState in the embedded code that uses a Derby-specific SQL State but which I think really should be a standard SQL state? For example, I think 42X89 (Types ''{0}'' and ''{1}'' are not type compatible. Neither type is assignable to the other type.) really is a case of the standard SQL State 22005 - error in assignment So the question is, using the taxonomy described in http://wiki.apache.org/db-derby/ForwardCompatibility should SQL States be Stable or Unstable? If they are Stable, then I can't fix this until 11.0, and I just need to log a bug for now. If they are Unstable, I can fix this in 10.2. I think really since our SQL States are documented, and we don't really think of them as experimental or transitional, then they should be considered Stable, and I really can't change an existing SQL State in a minor release. But when adding a new SQL state to the client, which takes priority: being consistent with the SQL state in embedded driver which is non-compliant with the standard, or being consistent with the SQL standard? I would vote for being consistent with the standard, and explain that the inconsistency is due to a bug in the embedded driver which will be fixed in the next major release. Thanks, David Kathey Marsden wrote: David W. Van Couvering wrote: Hi, all. I looked at the listing of Derby's public APIs (see http://wiki.apache.org/db-derby/ForwardCompatibility), and it mentions Derby's JDBC support. I need to delve in a little deeper. Are we guaranteeing compatibility for the SQL States? For the 10.2 release, is it OK for me to change the SQL State of an existing message, or do I need to keep it the same across minor releases? I don't think SQLStates are defined by the JDBC Standard but rather the SQL Standard. To that extent they should be compliant and match embedded where possible. SQLStates are documented but we have this caveat for client: http://db.apache.org/derby/docs/dev/ref/rrefexcept71493.html The following tables list /SQLStates/ for exceptions. Exceptions that begin with an /X/ are specific to Derby. Note that some SQLStates specific to the network client might change in future releases. We also voted early to make client match embedded where possible and that is in the documentation here. http://db.apache.org/derby/docs/dev/adminguide/cadminappsclientdiffs.html. I think that even within these guidelines early notification and buy in from the user community is key, so should be posted on the user list. and a Wiki page provided with information on how to write applications that will work on both old and new versions. But I think it is ok to change the SQLStates on client to: 1) Match the standard. 2) Match embedded. 3) Create a new SQLState instead of having a null SQLState for SQLExceptions that are specific to client. but not ok to : 1) Change client from some existing SQLState to another SQLState that is neither compliant nor matches embedded. I think message text can be changed, but the null SQLStates and message text are an interesting case, because before that was the only way for an app to check the error. I think some of our testing code does this. Kathey
Re: Compatibility guarantees for SQL states and messages
David W. Van Couvering wrote: Thanks, Kathey. What if I find an existing SQLState in the embedded code that uses a Derby-specific SQL State but which I think really should be a standard SQL state? For example, I think 42X89 (Types ''{0}'' and ''{1}'' are not type compatible. Neither type is assignable to the other type.) really is a case of the standard SQL State 22005 - error in assignment Ideally since these SQLState's are from the SQL Standard there should no I think about changing any. It should be driven from the specification, e.g. text that says ... then an exception condition is raised: data exception — error in assignment. In this specific case '22' is a data exception, some exception raised due to the value of the data. '42' is a compile time error, in this case raised because the types are not assignable to each other, not because the specific data values are not assignable to each other. We just need to be careful when selecting errors to ensure we are using SQL states correctly. Dan.
Re: Compatibility guarantees for SQL states and messages
Thanks, Dan. Believe me, I *am* trying to be careful when selecting SQL states. You don't know how tempted I am to just create new SQL States for everything so I can get this *done*. It is not fun slogging through (a) the existing code (b) the SQL standard for each and every error message in the client. At this rate you'll be lucky to see this work done in time for Rick's release in October :) I'll close that bug as not-a-bug. David Daniel John Debrunner wrote: David W. Van Couvering wrote: Thanks, Kathey. What if I find an existing SQLState in the embedded code that uses a Derby-specific SQL State but which I think really should be a standard SQL state? For example, I think 42X89 (Types ''{0}'' and ''{1}'' are not type compatible. Neither type is assignable to the other type.) really is a case of the standard SQL State 22005 - error in assignment Ideally since these SQLState's are from the SQL Standard there should no I think about changing any. It should be driven from the specification, e.g. text that says ... then an exception condition is raised: data exception — error in assignment. In this specific case '22' is a data exception, some exception raised due to the value of the data. '42' is a compile time error, in this case raised because the types are not assignable to each other, not because the specific data values are not assignable to each other. We just need to be careful when selecting errors to ensure we are using SQL states correctly. Dan.
Re: Compatibility guarantees for SQL states and messages
It sounds like your vote is that the SQL States be marked Unstable, not Stable. David Lance J. Andersen wrote: If it is deemed to be the wrong SQLState, then you should fix it. My experience is JDBC developers are more focused on the Exception and if they check further they often dig into the vendor error. This was a reason we added the SQLException sub classes to help aid in better portability. If you have not bought a copy of the SQL Standard you really do not know what this means (SQLState) anyways. my .02 David W. Van Couvering wrote: Thanks, Kathey. What if I find an existing SQLState in the embedded code that uses a Derby-specific SQL State but which I think really should be a standard SQL state? For example, I think 42X89 (Types ''{0}'' and ''{1}'' are not type compatible. Neither type is assignable to the other type.) really is a case of the standard SQL State 22005 - error in assignment So the question is, using the taxonomy described in http://wiki.apache.org/db-derby/ForwardCompatibility should SQL States be Stable or Unstable? If they are Stable, then I can't fix this until 11.0, and I just need to log a bug for now. If they are Unstable, I can fix this in 10.2. I think really since our SQL States are documented, and we don't really think of them as experimental or transitional, then they should be considered Stable, and I really can't change an existing SQL State in a minor release. But when adding a new SQL state to the client, which takes priority: being consistent with the SQL state in embedded driver which is non-compliant with the standard, or being consistent with the SQL standard? I would vote for being consistent with the standard, and explain that the inconsistency is due to a bug in the embedded driver which will be fixed in the next major release. Thanks, David Kathey Marsden wrote: David W. Van Couvering wrote: Hi, all. I looked at the listing of Derby's public APIs (see http://wiki.apache.org/db-derby/ForwardCompatibility), and it mentions Derby's JDBC support. I need to delve in a little deeper. Are we guaranteeing compatibility for the SQL States? For the 10.2 release, is it OK for me to change the SQL State of an existing message, or do I need to keep it the same across minor releases? I don't think SQLStates are defined by the JDBC Standard but rather the SQL Standard. To that extent they should be compliant and match embedded where possible. SQLStates are documented but we have this caveat for client: http://db.apache.org/derby/docs/dev/ref/rrefexcept71493.html The following tables list /SQLStates/ for exceptions. Exceptions that begin with an /X/ are specific to Derby. Note that some SQLStates specific to the network client might change in future releases. We also voted early to make client match embedded where possible and that is in the documentation here. http://db.apache.org/derby/docs/dev/adminguide/cadminappsclientdiffs.html. I think that even within these guidelines early notification and buy in from the user community is key, so should be posted on the user list. and a Wiki page provided with information on how to write applications that will work on both old and new versions. But I think it is ok to change the SQLStates on client to: 1) Match the standard. 2) Match embedded. 3) Create a new SQLState instead of having a null SQLState for SQLExceptions that are specific to client. but not ok to : 1) Change client from some existing SQLState to another SQLState that is neither compliant nor matches embedded. I think message text can be changed, but the null SQLStates and message text are an interesting case, because before that was the only way for an app to check the error. I think some of our testing code does this. Kathey
Re: Compatibility guarantees for SQL states and messages
My point is this. If there is an incorrect SQL state applied, then it is a bug simple as that. Changing these is pretty low risk anyways as the majority of developers do not have copies of the standard.I bet you will find a fair amount of divergence WRT some of the SQLStates returned if you were to survey all of the vendors out there. No facts, just gut feel based on my experience. Also keep in mind that the SQLState that is returned from a SQLException is also derived from XOpen and the ANSI SQL Standard.I would not dwell too much on this to be honest. Regards Lance David W. Van Couvering wrote: It sounds like your vote is that the SQL States be marked Unstable, not Stable. David Lance J. Andersen wrote: If it is deemed to be the wrong SQLState, then you should fix it. My experience is JDBC developers are more focused on the Exception and if they check further they often dig into the vendor error. This was a reason we added the SQLException sub classes to help aid in better portability. If you have not bought a copy of the SQL Standard you really do not know what this means (SQLState) anyways. my .02 David W. Van Couvering wrote: Thanks, Kathey. What if I find an existing SQLState in the embedded code that uses a Derby-specific SQL State but which I think really should be a standard SQL state? For example, I think 42X89 (Types ''{0}'' and ''{1}'' are not type compatible. Neither type is assignable to the other type.) really is a case of the standard SQL State 22005 - error in assignment So the question is, using the taxonomy described in http://wiki.apache.org/db-derby/ForwardCompatibility should SQL States be Stable or Unstable? If they are Stable, then I can't fix this until 11.0, and I just need to log a bug for now. If they are Unstable, I can fix this in 10.2. I think really since our SQL States are documented, and we don't really think of them as experimental or transitional, then they should be considered Stable, and I really can't change an existing SQL State in a minor release. But when adding a new SQL state to the client, which takes priority: being consistent with the SQL state in embedded driver which is non-compliant with the standard, or being consistent with the SQL standard? I would vote for being consistent with the standard, and explain that the inconsistency is due to a bug in the embedded driver which will be fixed in the next major release. Thanks, David Kathey Marsden wrote: David W. Van Couvering wrote: Hi, all. I looked at the listing of Derby's public APIs (see http://wiki.apache.org/db-derby/ForwardCompatibility), and it mentions Derby's JDBC support. I need to delve in a little deeper. Are we guaranteeing compatibility for the SQL States? For the 10.2 release, is it OK for me to change the SQL State of an existing message, or do I need to keep it the same across minor releases? I don't think SQLStates are defined by the JDBC Standard but rather the SQL Standard. To that extent they should be compliant and match embedded where possible. SQLStates are documented but we have this caveat for client: http://db.apache.org/derby/docs/dev/ref/rrefexcept71493.html The following tables list /SQLStates/ for exceptions. Exceptions that begin with an /X/ are specific to Derby. Note that some SQLStates specific to the network client might change in future releases. We also voted early to make client match embedded where possible and that is in the documentation here. http://db.apache.org/derby/docs/dev/adminguide/cadminappsclientdiffs.html. I think that even within these guidelines early notification and buy in from the user community is key, so should be posted on the user list. and a Wiki page provided with information on how to write applications that will work on both old and new versions. But I think it is ok to change the SQLStates on client to: 1) Match the standard. 2) Match embedded. 3) Create a new SQLState instead of having a null SQLState for SQLExceptions that are specific to client. but not ok to : 1) Change client from some existing SQLState to another SQLState that is neither compliant nor matches embedded. I think message text can be changed, but the null SQLStates and message text are an interesting case, because before that was the only way for an app to check the error. I think some of our testing code does this. Kathey
Compatibility guarantees for SQL states and messages
Hi, all. I looked at the listing of Derby's public APIs (see http://wiki.apache.org/db-derby/ForwardCompatibility), and it mentions Derby's JDBC support. I need to delve in a little deeper. Are we guaranteeing compatibility for the SQL States? For the 10.2 release, is it OK for me to change the SQL State of an existing message, or do I need to keep it the same across minor releases? What about the text of messages? I noticed that we changed these between 10.0 and 10.1, so I'm assuming these can change across minor release boundaries. What about across patch releases? Thanks, David