db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1589) CREATE TABLE throws NullPointerException in Derby SQL Standard Authorization after DROPs and REVOKES
Date Thu, 14 Sep 2006 02:33:23 GMT
    [ 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

        

Mime
View raw message