db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Commented: (DERBY-1162) Add mechanism to assert/compare SQLStates
Date Wed, 29 Mar 2006 17:56:31 GMT
David W. Van Couvering wrote:

> I again can't comment directly in JIRA as it is unavailable.
> 
> I was corrected by Dan on this some time ago, and I have to agree with
> him that since the SQLState class is not part of the public API we
> shouldn't be relying on it.
> 
> I think that if an individual tester wants to use something more
> descriptive than "25001" then they can create a constant for the string.
> 
> I think it might be worthwhile to create a utility test class that
> contains constants for all the SQL States that are currently being
> tested against.  One could even cut-and-paste from the SQL spec, which
> lists all standard SQL states using the following format
> 
> INVALID_TRANSACTION_STATE_ACTIVE_SQL_TRANSACTION:
> constant SQLSTATE_TYPE :="25001";
> 
> and then run some kind of sed script to turn it from their format to
> Java, and be good to go, e.g
> 
> public static final String
> INVALID_TRANSACTION_STATE_ACTIVE_SQL_TRANSACTION = "25001";

+1

> I can remove the assertSQLState from the BaseJDBCTestCase.  Maybe I'll
> get inspired and add the constants file too... :)

I think an assertSQLState is a good utility method. I only had conerns
over how it was going to be used and the truncation of the expected SQL
state to 5 characters. I would instead have additional asserts within
that the expected and actual SQL states are five characters long.

Dan.



Mime
View raw message