db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2410) Convert grantRevoke.java to JUnit
Date Wed, 21 Mar 2007 19:22:32 GMT

    [ 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)"

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:
>            Reporter: Andrew McIntyre
>         Assigned To: Andrew McIntyre
>             Fix For:
>         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.

View raw message