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
