[
https://issues.apache.org/jira/browse/DERBY-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295090#comment-15295090
]
Bryan Pendleton commented on DERBY-3181:
----------------------------------------
Hi Danoja, it is great to hear that the tests are working better now in your
environment.
I think that, to move ahead with this change, we need to improve our patch
slightly
so that we use a real Derby message for this error, rather than the hard-coded
"Invalid scope" string in the experimental patch we've been testing.
This is a good chance to learn how we add a new error message to Derby.
So this means:
1) Modify java/shared/org/apache/derby/shared/common/reference/SQLState.java
to define a new SQL state value for this error condition. I think you can
just
follow the pattern that is already in that file; try going to around line
950 in
that file, pick a new unused SQLState code (e.g., 42XAT, perhaps?), and give
it a friendly name, like LANG_INVALID_ROWID_SCOPE
2) Modify java/engine/org/apache/derby/loc/messages.xml to add your message
text.
Just go to the corresponding location in that file (that is, where your
SQLState
lines up with the other SQLStates in its range), and add a XML text block
that
provides a message about the invalid scope value.
I think that our error message should take the scope value as an argument, so
something like: "Invalid row identifier scope: {0}"
3) Then, we want our test code in DatabaseMetaDataTest.java to do more than
just catch-and-ignore the SQLException for invalid scope; we want it to check
that it got the right message in this case, so we need the catch block to say
assertSQLState( ...), like we do elsewhere in those tests (see around lines
3585, say)
After I add a new message, I always do a complete rebuild by doing
ant clobber cleanjars
ant all
Once you think you've got your proposed patch all tidied up, and you've checked
that the tests are still passing, please post your proposed final patch for
review.
Thanks!
> isNullable on ResultSetMetaData from DatabaseMetaData.getBestRowIdentifier
> values are opposite when there is no rows in ResultSet vs. when there is a
> row.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3181
> URL: https://issues.apache.org/jira/browse/DERBY-3181
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.4.1.3
> Reporter: Myrna van Lunteren
> Assignee: Danoja Dias
> Priority: Trivial
> Labels: derby_triage10_5_2
> Attachments: Derby-3181.diff, repro.java, testChange.diff
>
>
> With code like the following:
> DatabaseMetaData dmd = conn.getMetaData();
> ResultSet rs = dmd.getBestRowIdentifier(null,"APP","a",3,true);
> ResultSetMetaData rsmd = rs.getMetaData();
> int actualCols = rsmd.getColumnCount();
> for (int i = 0; i < actualCols; i++)
> {
> System.out.print("getColumnName: " + rsmd.getColumnName(i+1)
> + ", isNullable: ");
> System.out.println(rsmd.isNullable(i+1));
> }
> The printed values for isNullable returned are opposite of what they are when
> the getBestRowIdentifier call looks like this:
> ResultSet rs = dmd.getBestRowIdentifier(null,"APP","a",1,true);
> In the latter case, the values are:
> getColumnName: SCOPE, isNullable: 0
> getColumnName: COLUMN_NAME, isNullable: 1
> getColumnName: DATA_TYPE, isNullable: 0
> getColumnName: TYPE_NAME, isNullable: 1
> getColumnName: COLUMN_SIZE, isNullable: 0
> getColumnName: BUFFER_LENGTH, isNullable: 0
> getColumnName: DECIMAL_DIGITS, isNullable: 0
> getColumnName: PSEUDO_COLUMN, isNullable: 0
> In the first case, the values are:
> getColumnName: SCOPE, isNullable: 1
> getColumnName: COLUMN_NAME, isNullable: 0
> getColumnName: DATA_TYPE, isNullable: 1
> getColumnName: TYPE_NAME, isNullable: 1
> getColumnName: COLUMN_SIZE, isNullable: 1
> getColumnName: BUFFER_LENGTH, isNullable: 1
> getColumnName: DECIMAL_DIGITS, isNullable: 1
> getColumnName: PSEUDO_COLUMN, isNullable: 1
> The isNullable value should be stable.
> It's probably worthwhile verifying what the value *should* be in the first
> place.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
