David W. Van Couvering wrote:
Kristian Waagan (JIRA) wrote:
[
http://issues.apache.org/jira/browse/DERBY-1149?page=comments#action_12372240
]
Kristian Waagan commented on DERBY-1149:
----------------------------------------
This patch will (and does) fail, due to the way SQLStates are
compared. I will brush up the patch, only changing things in
StatementTest, were this testing was not good enough (all tests, not
only the one that failed here).
The name SQLState.java is actually misleading. These are really
message ids being defined, *not* SQL States.
The SQLStates are derived from the message ids as the first five
characters of the message id.
See the method
org.apache.derby.shared.common.error.ExceptionUtil.getSQLStateFromIdentifier().
I was also misled by this. We shouldn't use SQLState constants when
checking the SQL State.
We have to use the actual five-character SQLState.
I havn't looked at the ExceptionUtil method, but I guess it is another
substring(0,5) - as the one in StandardException.
I'l take a look at your change and see if that does what we need to do.
Well, it does and it doesn't. It trucates the incoming string, but since
I have used a disallowed comparison (referring SQLState in the test),
the patch must be modified again.
You know, I must be running the jdbc40 tests wrong, because it came
out with a success when it obviously should have been a failure. I
will look into this.
Nothing magic, just remember to use JDK 1.6 when running (put it first
in path or something). You should see the JVM version from the output.
Besides from that, nothing special is required to run the suite.
David, can you explain why you have set the SQLState to "25000.S.1",
and not to "25001"?
Is the former an SQLState encoding exception category, as described
in the class comments for SQLState.java?
Yes, it should be 25001, I somehow missed that in our original
exchange; rereading your email (http://tinyurl.com/l4xwr) you were
referring to 25001, not 25000.
The former was when I was assuming that we had two messages for the
same SQL State (25000), in which case they are distinguished with a
suffix number. Due to the way exception severity is determined (using
a default or by using the ".N" suffix after the first five
characters), you have to append the severity and then the suffix
number, e.g. 25000.S.1.
See
http://www.nabble.com/Multiple-causes-for-same-SQL-State-t991637.html#a2568667
Okay, I see. I was confused by the comment in SQLState, talking about
chars 8 and 9 begin some kind of exception category. Couldn't get it to
match with your naming. I have also seen a few identifiers using 3
digits at the end, so that the total length gets up to 11.
Do we want to use the invalid trasaction state also for XA
connections? I see it has been added in EmbedXAConnection. Is the
CANNOT_CLOSE_ACTIVE_XA_CONNECTION wrong/deprecated for XA connections?
I think that we want to use the invalid transaction state (25001 -
active SQL-transaction) for XA connections as well. Is there a reason
they should be treated differently?
Not that I know of, I was just asking :) I guess the XA message is a
Derby specific thing/leftover.
I posted an updated patch on Jira, changing the identifer and the
StatementTest SQLState comparions. I have no more questions to the patch.
--
Kristian
Thanks for looking at this.
David
Besides from these questions, I think the patch is good to go, but I
would appreciate if it was held back until the questions above were
answered and I had the time to add some fixes to StatementTest.
'jdbc40/StatementTest.junit' fails under DerbyNetClient
-------------------------------------------------------
Key: DERBY-1149
URL: http://issues.apache.org/jira/browse/DERBY-1149
Project: Derby
Type: Test
Components: Regression Test Failure, Test
Versions: 10.2.0.0
Environment: JDK 1.6 (b76 used, believed to apply to all)
Reporter: Kristian Waagan
Assignee: David Van Couvering
Attachments: DERBY-1149-StatementTestFaiure.diff
One of the tests in jdbc40/StatementTest.junit fails with the
following message:
"Attempt to shutdown framework: DerbyNetClient
0 add
....F.
There was 1 failure:
1)
testIsClosedWhenClosingConnectionInInvalidState(org.apache.derbyTesting.functionTests.tests.jdbc4.StatementTest)junit.framework.ComparisonFailure:
Unexpected exception thrown: Cannot close a connection while a
global transaction is still active.
expected:<java.sql.Connection.close() requested while a transaction
is in progress on the connection.The transaction remains active,
and the connection cannot be closed...> but was:<Cannot close a
connection while a global transaction is still active...>
FAILURES!!!
Tests run: 5, Failures: 1, Errors: 0
Test Failed.
*** End: StatementTest jdk1.6.0-beta2 DerbyNetClient 2006-03-24
12:53:22 ***"
The reason is that the exception message text has been changed. This
comparison is only done when running DerbyNetClient, because
SQLState was not implemented there.
The checkin that caused the error:
"Author: davidvc
Date: Thu Mar 23 16:55:44 2006
New Revision: 388309
URL: http://svn.apache.org/viewcvs?rev=388309&view=rev
Log:
DERBY-839 (Partial). Internationalize Connection.java. Also upgraded
the "i18n lint" test to be a little more intelligent, and to not exit
on the first failure.
Passes derbynetclientmats. All changes are client-specific so derbyall
was not run."
A
