Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <30544189.1178055015677.JavaMail.jira@brutus>
Date: Tue, 1 May 2007 14:30:15 -0700 (PDT)
From: "Dyre Tjeldvoll (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2594) Revoking a privilege from an SQL
 Object should invalidate statements dependent on that object
In-Reply-To: <22741942.1177587435446.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492954 ] 

Dyre Tjeldvoll commented on DERBY-2594:
---------------------------------------

Hi Bryan, I'm glad you think it is useful. I guess I could include it, but there are some caveats:

- Currently the trace is printed unconditionally. If it was to be committed I think I would have to put some SanityManager magic around it so that you only got this trace when setting a certain property (value).

- The change I have shown above is not very general and makes use of "bad" downcasts that in turn requires the import of files the DependencyManager ideally shouldn't have to know about.

- The DependencyManager already has a method called dumpDependencies() (or similar) which prints all the dependencies. I tried using that method but it generates so much output that it becomes really hard to find what you're looking for (especially if you call this method more than once). Part of the problem is that it relies on the Provider's and Dependent's toString() methods, which (for good reasons) generate far more output than is typically desired when looking at dependencies (in the case of GPSs it actually generates too little, only the UUID).

- Ideally the Provider and Dependent interfaces should provide a describe method that would give the right amount of info for printing dependencies. That way the DependencyManager itself would not have to downcast to the exact types. It would also be good to have the ability to filter out the subset of dependencies that you were interested in.

- Finally I believe I have seen in another Jira that Dan would like to re-design/re-write the DependencyManager at some point.

So I guess I won't include this as part of the main patch, but I'm happy to attach it as a separate patch. 
And if the DependencyManager won't be re-written right away, I could try to make another patch based on my comments here (would need some more time for that though) 

> Revoking a privilege from an SQL Object should invalidate statements dependent on that object
> ---------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2594
>                 URL: https://issues.apache.org/jira/browse/DERBY-2594
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 10.2.1.6
>            Reporter: Dyre Tjeldvoll
>         Assigned To: Dyre Tjeldvoll
>         Attachments: revoke_prelim.diff
>
>
> Revoking a privilege on a table will currently cause the DependencyManager.invalidateFor() to be called on the table's TablePermsDescriptor with the action=REVOKE_PRIVILEGE. However, the prepared statements that refer to that table are dependents of the table's TableDescriptor, but NOT its TablePermsDescriptor, so the statements are not invalidated after revoke.
> This problem is currently hidden by the fact that authorization is checked on every execution, but this will change when language result sets are no longer reused (see DERBY-827). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.