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: Stored Prepared Statements? -- Thoughts on exposing StorablePreparedStatements to user/external statements
Date Tue, 21 Apr 2009 19:48:45 GMT
Rick Hillegas <Richard.Hillegas@Sun.COM> writes:

> In order to persist ordinary user statements, we will need to think
> carefully about every bit of compiled state which was added to
> executable statements after cloudscape removed support for storing
> user statements. For instance, I believe that when GRANT/REVOKE was
> added, there was no need to persist the compiled list of required
> permissions. I don't see this list being persisted in
> GenericStorablePreparedStatement.writeExternal().

With the roles work, I did verify that the prepared stms of triggers
were recompiled when permissions or roles were revoked/deleted, so it
should be possible similarly to ensure that persisted user statements
get invalidated as a result of DDL ops as well, although the kind of
dependencies would differ. Ensuring that such dependencies are
registered as persistent (entry in SYS.SYSDEPENDS, not just in-memory
dependency) for persisted user statements would be sufficient and
necessary (plus making DDL ops invalidate dependents). Should not be
too hard, but testing is crucial.

Note that since prepared statements are shared, they will not be
dependent on any session's actual permissions, since those vary, and
are checked when the first activation for that prepared statement is
constructed, so one does need to persist the list of required
permissions, to be able to carry out that checking.

Dag

Mime
View raw message