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.
