[
https://issues.apache.org/jira/browse/DERBY-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482885
]
Andrew McIntyre commented on DERBY-2410:
----------------------------------------
dan>This is documented in the javadoc for DatabaseMetaData , e.g.
"tableNamePattern - a table name pattern; must match the table name as it is
stored in the database" If DERBY-2092 was addressed then it would be part of
Derby's documentation set.
I was surprised that there was no mention of this implementation detail
anywhere in the reference guide, i.e. the reference guide never mentions what
is 'the table name as it is stored in the database' as far as I can tell. The
actual behavior itself was not surprising, just ran into it after passing
around schema / tablenames as Strings and ending up with empty ResultSets for
some DatabaseMetaData methods in some cases, so I checked the docs and did not
find it mentioned there.
dan> I didn't understand this paragraph, not sure what a "universal test" is,
and this comment lost me "grant and have references privilege on a column for
which it has no meaning to have that privilege"
Sorry, it was late and I could have been more clear here. It is possible to
grant references privilege on any column, not just primary keys or unique
constraints. You can grant references on any column in the database, and Derby
happily records that privilege, and you can see in the test that this privilege
on the column can be confirmed from the metadata.
I checked the SQL standard, grant for references seems to be allowed to be
granted on arbitrary tables / columns in case those table / columns in the
grant are at some point modified to have / be a primary key or have a unique
constraint placed on them. However, having the privilege doesn't mean you can
do anything useful with it without a primary key or unique constraint on the
table / column, and there's no way to check the use of it without modifying the
original table. i.e. in the style of the test:
"create table foo (c1 int not null primary key, c2)"
grant("references"..."c2");
assertReferencePrivilege("true"..."c2");
passes if you just check the metadata for the privilege, but you can't test in
the assert method that you have references privilege on c2 without modifying
table foo in the assert method. I feel this sort of violates the spirit of the
assert tests, in that they shouldn't be changing the state of the things being
asserted, just verifying their state. It's probably also why this check in the
previous test was left stubbed out, since there's no good check for it that
doesn't alter the original table's definition.
It's not a problem, just making a note of it for the next person who comes
along and wonders what is going on here. I'll go back and double-check the
comments in the test to make sure they are clear.
> Convert grantRevoke.java to JUnit
> ---------------------------------
>
> Key: DERBY-2410
> URL: https://issues.apache.org/jira/browse/DERBY-2410
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Reporter: Andrew McIntyre
> Assigned To: Andrew McIntyre
> Fix For: 10.3.0.0
>
> Attachments: derby-2410-pre.diff, derby-2410-pre2.diff,
> derby-2410-pre3.diff, derby-2410-pre4.diff, derby-2410-pre5.diff,
> derby-2410-v1.diff
>
>
> Convert grantRevoke.java to JUnit. Also add test cases from grantRevokeDDL
> and grantRevokeDDL2 SQL tests to the new GrantRevokeTest
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
