You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <de...@db.apache.org> on 2006/03/29 14:16:20 UTC
[jira] Created: (DERBY-1162) Add mechanism to assert/compare
SQLStates
Add mechanism to assert/compare SQLStates
-----------------------------------------
Key: DERBY-1162
URL: http://issues.apache.org/jira/browse/DERBY-1162
Project: Derby
Type: Sub-task
Components: Test
Versions: 10.2.0.0
Environment: JUnit test environment
Reporter: Kristian Waagan
Assigned to: Kristian Waagan
Priority: Minor
The JUnit test environment needs a mechanism to assert/compare SQLStates. The goal is to be able to reference states from SQLState without having to care if the length of the identifier is 5,7 or more characters long.
A way to do this already exist in StandardException.getSQLStateFromIdentifier, but it is too unwieldy and long. I suggest adding 'assertSQLState(String, String, SQLException)' method to BaseJDBCTestCase.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1162) Add mechanism to assert/compare
SQLStates
Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1162?page=all ]
Kristian Waagan closed DERBY-1162:
----------------------------------
Change verified.
> Add mechanism to assert/compare SQLStates
> -----------------------------------------
>
> Key: DERBY-1162
> URL: http://issues.apache.org/jira/browse/DERBY-1162
> Project: Derby
> Type: Sub-task
> Components: Test
> Versions: 10.2.0.0
> Environment: JUnit test environment
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-1162-1a.diff
>
> The JUnit test environment needs a mechanism to assert/compare SQLStates. The goal is to be able to reference states from SQLState without having to care if the length of the identifier is 5,7 or more characters long.
> A way to do this already exist in StandardException.getSQLStateFromIdentifier, but it is too unwieldy and long. I suggest adding 'assertSQLState(String, String, SQLException)' method to BaseJDBCTestCase.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1162) Add mechanism to assert/compare
SQLStates
Posted by Kristian Waagan <Kr...@Sun.COM>.
Daniel John Debrunner (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-1162?page=comments#action_12372258 ]
>
> Daniel John Debrunner commented on DERBY-1162:
> ----------------------------------------------
>
> SQLStates are always five characters so I'm not sure why the method needs to truncate the expected value.
>
> From the comments in the description it seems as though you are expecting tests should use constants from the engine's SQLState.
> That is not good practice, it is not part of the public api and it can lead to hidden bugs.
>
> If a test is checking for SQLState.SOME_ERROR in a test, then if a error in coding changes that, say from a SQL Standard 23001 error
> to 2E001 then the test will continue to pass, even though a bug was introduced.
I've seen this approach been used before in tests.
Do you suggest we instead "hardcode" the SQLStates, i.e. instead of
SQLState.SOME_ERROR we use "23001"?
I see your point, but aren't the odds for an incorrect change in
SQLState a lot higher than a piece of code throwing the incorrect
SQLState? These changes are most likely reviewed before they are
committed. Also, the use of constants are usually more verbose and gives
more information than just using the 5 character SQLState. One can of
course create own local constants.
We will still catch the errors where SQLState.THIS_ERROR is thrown
instead of SQLState.SOME_ERROR, which are the errors I have in mind when
writing tests. I have never thought of testing if the values in
SQLState.java are correct. I don't even have the required knowledge to
know what SQLState is the correct one to be used, I usually just make it
occur and if it has a reasonable message, I check for it in my test.
Should we revert the change to BaseJDBCTestCase and start using
hardcoded values or create test local constants for SQLStates?
--
Kristian
>
>> Add mechanism to assert/compare SQLStates
>> -----------------------------------------
>>
>> Key: DERBY-1162
>> URL: http://issues.apache.org/jira/browse/DERBY-1162
>> Project: Derby
>> Type: Sub-task
>> Components: Test
>> Versions: 10.2.0.0
>> Environment: JUnit test environment
>> Reporter: Kristian Waagan
>> Assignee: Kristian Waagan
>> Priority: Minor
>> Fix For: 10.2.0.0
>> Attachments: DERBY-1162-1a.diff
>>
>> The JUnit test environment needs a mechanism to assert/compare SQLStates. The goal is to be able to reference states from SQLState without having to care if the length of the identifier is 5,7 or more characters long.
>> A way to do this already exist in StandardException.getSQLStateFromIdentifier, but it is too unwieldy and long. I suggest adding 'assertSQLState(String, String, SQLException)' method to BaseJDBCTestCase.
>
Re: [jira] Commented: (DERBY-1162) Add mechanism to assert/compare
SQLStates
Posted by Daniel John Debrunner <dj...@apache.org>.
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.
Re: [jira] Commented: (DERBY-1162) Add mechanism to assert/compare
SQLStates
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
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";
I can remove the assertSQLState from the BaseJDBCTestCase. Maybe I'll
get inspired and add the constants file too... :)
David
Daniel John Debrunner (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-1162?page=comments#action_12372258 ]
>
> Daniel John Debrunner commented on DERBY-1162:
> ----------------------------------------------
>
> SQLStates are always five characters so I'm not sure why the method needs to truncate the expected value.
>
> From the comments in the description it seems as though you are expecting tests should use constants from the engine's SQLState.
> That is not good practice, it is not part of the public api and it can lead to hidden bugs.
>
> If a test is checking for SQLState.SOME_ERROR in a test, then if a error in coding changes that, say from a SQL Standard 23001 error
> to 2E001 then the test will continue to pass, even though a bug was introduced.
>
>
>>Add mechanism to assert/compare SQLStates
>>-----------------------------------------
>>
>> Key: DERBY-1162
>> URL: http://issues.apache.org/jira/browse/DERBY-1162
>> Project: Derby
>> Type: Sub-task
>> Components: Test
>> Versions: 10.2.0.0
>> Environment: JUnit test environment
>> Reporter: Kristian Waagan
>> Assignee: Kristian Waagan
>> Priority: Minor
>> Fix For: 10.2.0.0
>> Attachments: DERBY-1162-1a.diff
>>
>>The JUnit test environment needs a mechanism to assert/compare SQLStates. The goal is to be able to reference states from SQLState without having to care if the length of the identifier is 5,7 or more characters long.
>>A way to do this already exist in StandardException.getSQLStateFromIdentifier, but it is too unwieldy and long. I suggest adding 'assertSQLState(String, String, SQLException)' method to BaseJDBCTestCase.
>
>
[jira] Commented: (DERBY-1162) Add mechanism to assert/compare
SQLStates
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1162?page=comments#action_12372258 ]
Daniel John Debrunner commented on DERBY-1162:
----------------------------------------------
SQLStates are always five characters so I'm not sure why the method needs to truncate the expected value.
>From the comments in the description it seems as though you are expecting tests should use constants from the engine's SQLState.
That is not good practice, it is not part of the public api and it can lead to hidden bugs.
If a test is checking for SQLState.SOME_ERROR in a test, then if a error in coding changes that, say from a SQL Standard 23001 error
to 2E001 then the test will continue to pass, even though a bug was introduced.
> Add mechanism to assert/compare SQLStates
> -----------------------------------------
>
> Key: DERBY-1162
> URL: http://issues.apache.org/jira/browse/DERBY-1162
> Project: Derby
> Type: Sub-task
> Components: Test
> Versions: 10.2.0.0
> Environment: JUnit test environment
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-1162-1a.diff
>
> The JUnit test environment needs a mechanism to assert/compare SQLStates. The goal is to be able to reference states from SQLState without having to care if the length of the identifier is 5,7 or more characters long.
> A way to do this already exist in StandardException.getSQLStateFromIdentifier, but it is too unwieldy and long. I suggest adding 'assertSQLState(String, String, SQLException)' method to BaseJDBCTestCase.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1162) Add mechanism to assert/compare
SQLStates
Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1162?page=all ]
Kristian Waagan updated DERBY-1162:
-----------------------------------
Attachment: DERBY-1162-1a.diff
'DERBY-1162-1a.diff' adds method 'assertSQLState' to BaseJDBCTestCase.
Please review/commit.
> Add mechanism to assert/compare SQLStates
> -----------------------------------------
>
> Key: DERBY-1162
> URL: http://issues.apache.org/jira/browse/DERBY-1162
> Project: Derby
> Type: Sub-task
> Components: Test
> Versions: 10.2.0.0
> Environment: JUnit test environment
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Attachments: DERBY-1162-1a.diff
>
> The JUnit test environment needs a mechanism to assert/compare SQLStates. The goal is to be able to reference states from SQLState without having to care if the length of the identifier is 5,7 or more characters long.
> A way to do this already exist in StandardException.getSQLStateFromIdentifier, but it is too unwieldy and long. I suggest adding 'assertSQLState(String, String, SQLException)' method to BaseJDBCTestCase.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1162) Add mechanism to assert/compare
SQLStates
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1162?page=all ]
Knut Anders Hatlen resolved DERBY-1162:
---------------------------------------
Fix Version: 10.2.0.0
Resolution: Fixed
Looks good. Committed revision 389783.
> Add mechanism to assert/compare SQLStates
> -----------------------------------------
>
> Key: DERBY-1162
> URL: http://issues.apache.org/jira/browse/DERBY-1162
> Project: Derby
> Type: Sub-task
> Components: Test
> Versions: 10.2.0.0
> Environment: JUnit test environment
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-1162-1a.diff
>
> The JUnit test environment needs a mechanism to assert/compare SQLStates. The goal is to be able to reference states from SQLState without having to care if the length of the identifier is 5,7 or more characters long.
> A way to do this already exist in StandardException.getSQLStateFromIdentifier, but it is too unwieldy and long. I suggest adding 'assertSQLState(String, String, SQLException)' method to BaseJDBCTestCase.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira