db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: Issues with SQL Roles
Date Tue, 14 Apr 2009 17:07:53 GMT
Rick Hillegas <Richard.Hillegas@Sun.COM> writes:

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

Yes, this is the current behavior. I think we should keep this.  The
privilege checking occurs at execute time (when the result set is
constructed), and I guess it's logical that if you can see *one* row
with a SELECT privilege, you should be able to see them all. In any
case, prefetching of rows at several levels in Derby makes it hard to
present a consistent picture if we chose to try to make enforcement
immediate. I could not find anything in the standard on this.

It is not there alrady it should be mentioned in the docs.


View raw message