[
https://issues.apache.org/jira/browse/DERBY-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew McIntyre updated DERBY-2410:
-----------------------------------
Attachment: derby-2410-v1.diff
Attaching first complete patch for this issue. The new test covers all
functionality covered by grantRevoke.java minus the column privilege checking
that requires the use of FormatableBitSet, which is an internal API that the
tests should not be using.
Three issues were encountered during the conversion of this test. They all seem
to be expected, but undocumented, behavior:
- DatabaseMetaData methods require that the schema and tablename be uppercased.
Passing lowercase names to the create / grant / revoke statements work as
expected, but then using the same lowercase names with DatabaseMetaData returns
an empty ResulSet for the metadata. This is obvious when looking at the
metadata queries and how the metadata is returned to the user. The lack of
documentation of this behavior surprised me more than anything.
- as mentioned in a previous mail, privileges granted by the database owner in
an open transaction block user transactions for the same column/table because
grant/revoke statements are always executed with repeatable read isolation
level. From reading the code, this is expected, but doesn't appear to be
documented anywhere. I've been meaning to double-check this behavior with the
old test (which, on first reading, seems to allow concurrent read of grant
permissions by owner and user transactions), but haven't had the time to get
the test running in the debugger with the old harness to check.
- Table level privileges are not recorded in SYSCOLPERMS and column level
privileges where the set of columns is equivalent to the set of columns in the
table is not recorded in SYSTABLEPERMS. Again, I believe this to be expected -
but not obvious - behavior.
other comments:
- I feel that a true universal test for references privilege is impossible,
since it requires that the referenced column be a primary key or unique
constraint. i.e. it is possible to grant and have references privilege on a
column for which it has no meaning to have that privilege. Therefore, no
meaningful universal test for that privilege can be crafted. That said, I left
an untested implementation for an assert of the privilege in
assertReferencesPrivilege() for future use, for cases where we know the table
has a primary key that can be referenced, or a unique constraint that can be
referenced.
- Some RESOLVE comments from the previous version of the test were preserved,
primarily in the decorateSQL method, concerning support for grant / revoke with
certain database features.
If there are no comments, I'll commit this tomorrow afternoon and remove
grantRevoke.java. Converting grantRevokeDDL.java and grantRevokeDDL2.java
completely to JUnit may be more trouble than it is worth in the long run. I'm
looking into converting the 15 to 16 testcases that cause differences between
platforms into GrantRevokeTest and then leaving the rest of the old
grantRevokeDDL tests to run under LangScriptTests.
> 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.
