Hi Tiago,
I believe that this behavior is deliberate and expected. I believe that
permissions are not checked on every fetch from a ResultSet but that,
instead, an in-flight ResultSet remains usable even though permissions
may change after the ResultSet is opened. This, at least, is the sense I
get from Dag's August 26, 2008 comment on
http://issues.apache.org/jira/browse/DERBY-3223 Here's a quote from the
comment:
"Any open result sets will remain usable as before, since these remain
open; even though the old (base)activation is no longer referenced
from the GenericActivationHolder, there is a reference to the old
activation from the result set, so it stays alive."
Dag may want to comment further.
Hope this helps,
-Rick
Tiago Espinha wrote:
Hey everyone,
I have been throwing tests at the SQL Roles. At this point I get a
certain behavior and perhaps Rick or Dag can give me some insight on
whether this is the expected behavior or if it is a bug.
So, I'm not totally sure of how cursors work underneath, and I decided
to run a simple test:
1. Create the role testCursor with SELECT privileges on table t1
2. Grant the role testCursor to the userTest
3. With userTest get a cursor for t1
4. Without closing the cursor, revoke the SELECT privileges to userTest
5. Try to move the cursor forward
Here the cursor keeps going until it reaches the end of the table;
this is, revoking the privileges doesn't affect the cursor. Is this
expected?
Tiago
