[ http://issues.apache.org/jira/browse/DERBY-1589?page=comments#action_12434577 ] Bryan Pendleton commented on DERBY-1589: ----------------------------------------
I think that the problem involves the prepared statement cache and how statements get invalidated. Notice that the very last statement is a CREATE TABLE statement which is identical in text to a CREATE TABLE statement issued earlier in the script, though it refers to table t11ConstraintTest which has been dropped and recreated in the meantime. Tracing through the code, it seems that when we hit the last line of the script, the compiler locates information about the first CREATE TABLE statement and re-uses it, but since that cached statement refers to a table that no longer exists, the permission checking code gets an NPE trying to look up information about the non-existent table. If I change the last line of the script to: create table t31ConstraintTest (c311 int, c312 int, a int, foreign key(c311, c312) references mamta1.t11ConstraintTest); then the problem does not occur. I believe this is because the old statement information does not get re-used because the statement text is different. I think this means I get to go learn about how prepared statements are cached and how that cache is invalidated. > CREATE TABLE throws NullPointerException in Derby SQL Standard Authorization > after DROPs and REVOKES > ---------------------------------------------------------------------------------------------------- > > Key: DERBY-1589 > URL: http://issues.apache.org/jira/browse/DERBY-1589 > Project: Derby > Issue Type: Bug > Components: SQL > Affects Versions: 10.2.1.0 > Reporter: Daniel John Debrunner > Assigned To: Bryan Pendleton > Fix For: 10.2.1.0 > > > Currently, the last sql statement in following set of sql statements will > raise a null pointer exception > connect 'jdbc:derby:c:/dellater/dbmaintest2;create=true' user 'mamta1' as > mamta1; > create table t11ConstraintTest (c111 int not null, c112 int not null, primary > key (c111, c112)); > grant references on t11ConstraintTest to mamta3; > connect 'jdbc:derby:c:/dellater/dbmaintest2;create=true' user 'mamta3' as > mamta3; > drop table t31ConstraintTest; > -- the following statement should remember that it depends on REFERENCES > privilege on mamta1.t11ConstraintTest > create table t31ConstraintTest (c311 int, c312 int, foreign key(c311, c312) > references mamta1.t11ConstraintTest); > drop table t31ConstraintTest; > set connection mamta1; > -- following should revoke all the privileges granted on it > drop table t11ConstraintTest; > create table t11ConstraintTest (c111 int not null, c112 int not null, primary > key (c111, c112)); > grant references(c111) on t11ConstraintTest to mamta3; > grant references(c112) on t11ConstraintTest to PUBLIC; > --connect 'jdbc:derby:c:/dellater/dbmaintest2;create=true' user 'mamta3' as > mamta3; > set connection mamta3; > drop table t31ConstraintTest; > -- following sql should recompie itself because the earlier plan depended on > a privilege which doesn't > -- exist anymore. Instead, new privileges have been granted and the plan for > following statement should depend > -- on those new privileges > create table t31ConstraintTest (c311 int, c312 int, foreign key(c311, c312) > references mamta1.t11ConstraintTest); -- 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
