db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1502) Non-deterministic behavior of lang/grantRevokeDDL.sql
Date Tue, 11 Jul 2006 21:06:32 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1502?page=comments#action_12420437 ] 

Mamta A. Satoor commented on DERBY-1502:
----------------------------------------

There was some discussion on this diff in DERBY-1330 and on the derby list. I am copying them
in chronological order here to track the discussion

<start comment from Knut Anders Hatlen>
I have seen this regression test failure a couple of times lately. Could it be related to
this issue? 

********* Diff file derbyall/derbylang/grantRevokeDDL.diff 
*** Start: grantRevokeDDL jdk1.5.0_04 derbyall:derbylang 2006-07-10 09:56:26 *** 
560 del 
< ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table
'MAMTA2'.'V22'. 
560a560 
> ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table
'MAMTA2'.'V21'. 
Test Failed. 
*** End: grantRevokeDDL jdk1.5.0_04 derbyall:derbylang 2006-07-10 09:56:37 *** 

It seems to happen on both Solaris and Linux, JVM 1.4 and 1.5: 
http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.9-34.ELsmp_x86_64-x86_64/420328-derbylang_diff.txt

http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.10_i86pc-i386/420328-derbylang_diff.txt

http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/testlog/Linux-2.6.9-34.ELsmp_x86_64-x86_64/420328-derbyall_diff.txt

http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/testlog/SunOS-5.10_i86pc-i386/420328-derbyall_diff.txt


It does not happen on the tinderbox, though. 
<end comment from Knut Anders Hatlen>



<start comment from Mamta Satoor>
Knut, the diffs you are noticing is in one of the new tests that I added to grantRevokeDDL.sql


The diff is for following sql which is executed by mamta3(Note that mamta3 does not have SELECT
privilege on mamta2.v22.c111 and on mamta2.v21.c111 but does have SELECT privilege on mamta1.t11)


create view v33 as select v22.c111 as a, t11.c111 as b from mamta2.v22 v22, mamta1.t11 t11,
mamta2.v21; 

When this create view is compiled by Derby, it collects the privileges required by the create
view. Derby collects following privilege requirements for the create view sql above 
1)SELECT on mamta2.v22 
2)SELECT on mamta1.t11 
3)SELECT on mamta2.v21 
4)ownership of the schema in which create view is being issued 

Later on, at create view execution time, Derby grows through the required privileges list
and checks if mamta3 has the required privileges or not. And since mamta3 does not have the
required privileges on mamta2.v22 and mamta2.v21, the create view fails. 

In the diff that you posted above, both the error messages are correct. It seems like 
1)either the order in which the privilege requirements get added to the list in compile phase
is not always the same 
2)or the order in which privileges get retrieved in the execution phase is not always the
same 
and hence different error messages 

CompilerContextimpl.addRequiredTablePriv() has following 
requiredTablePrivileges.put(key, key); 
and requiredTablePrivileges is defined as follows in CompilerContextimpl 
private HashMap requiredTablePrivileges; 

Is this a Java behavior that you can count on the order in which items will be added and retrieved
from HashMap? 

At this point, I am not sure, how to make sure that items get added and retrieved in the same
order from the HashMap so that we will have consistent error message return from the create
view sql above. Any insight from the list will be appreciated. 
<end comment from Mamta Satoor>




<start comment from Mamta Satoor>
Mike responded following on the mailing list 
<quote> 
I do not believe you can count on the order of a HashMap, different 
JVM's may use different hash algo's which may result in different orders 
when you ask for the full list. I have seen this behavior in queries 
which use hash nodes in derby (I believe we first noticed a difference 
between j9 and other jvm's). In that case we added order by's as 
necessary to the tests, as either order of results was correct from 
SQL point of view. 

In your case is the order a code problem, or just a testing issue? 
</quote> 

First of all, thanks Mike for your response. 

As to your question, the order is not a testing issue because test is simply trying a scenario
where a user is trying to create a object based on more than one object on which the user
doesn't have access to. And depending on how items got into HashMap, the test fails with privilege
error on one object vs the other. So, in this case, the order is a code problem. 
<end comment from Mamta Satoor>



<start comment from Mike Matrigali>
If the order of the error is not documented, then I am not sure it is a
code error.  Sort of similar to the fact that on different jvm's derby
will return rows in different orders for the same db, same query (unless
a specific order by is used).
I would define it as a test problem, as the test assumes a specific
error where either of 2 errors is valid.

The code could use some sorting mechanism to guarantee an ordering, but
it would have to be careful about the key (object id's could also vary
from machine to machine, or time to time).  Doing so would likely mean
more memory and more code, doesn't seem worth it to me for this case -
anyone think so?
<end comment from Mike Matrigali>


<start comment from Knut Anders Hatlen>
I agree. Since the SQL state is equal in the two cases, I think a sed
script that strips everything but the message would be OK. Something
like this in grantRevokeDDL_sed.properties:

substitute=^ERROR ([^:]*):.*$;ERROR: Failed with SQLSTATE $1


> The code could use some sorting mechanism to guarantee an ordering, but
> it would have to be careful about the key (object id's could also vary
> from machine to machine, or time to time).  Doing so would likely mean
> more memory and more code, doesn't seem worth it to me for this case -
> anyone think so?


Perhaps a LinkedHashMap would do the trick, but I agree, I don't think
it's worth it.
<end comment from Knut Anders Hatlen>



> Non-deterministic behavior of lang/grantRevokeDDL.sql
> -----------------------------------------------------
>
>          Key: DERBY-1502
>          URL: http://issues.apache.org/jira/browse/DERBY-1502
>      Project: Derby
>         Type: Bug

>   Components: Regression Test Failure
>     Versions: 10.2.0.0
>  Environment: linux, jdk1.4 and jdk 1.5
>     Reporter: Rick Hillegas
>     Assignee: Mamta A. Satoor
>      Fix For: 10.2.0.0

>
> Sometimes I see the following failure in lang/grantRevokeDDL.sql. I have seen this on
linux under jdk 1.4 and 1.5.
> 560 del
> < ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table
'MAMTA2'.'V22'.
> 560a560
> > ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table
'MAMTA2'.'V21'.
> Test Failed.
> *** End:   grantRevokeDDL jdk1.4.2_08 2006-07-11 13:38:51 ***
> It would appear that when two permissions are inadequate, it's not clear which one will
fail the statement.

-- 
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