Yes, that is what I had originally tried, which is to have the ConstraintDescriptor.makeInvalid call following when it receives REVOKE_PRIVILEGE action
getDataDictionary().dropConstraintDescriptor(getTableDescriptor(), this, lcc.getTransactionExecute());
But looks like that is not sufficient to have all the other data structures clean themselves off of the constraint descriptor. For instance, after the call above, TableDescriptor still had the conglomerate of the constraint's backing index attached to it.
thanks,
Mamta
On 7/12/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Mamta Satoor wrote:
> Hi,
>
> I spent some time prototyping revoke privilege for foreign key constraint
> based on my proposal earlier in this thread.
> I added following code to ConstraintDescriptor.makeInvalid
>
> if (action == DependencyManager.REVOKE_PRIVILEGE)
> {
> PreparedStatement ps = lcc.prepareInternalStatement("alter table "+
> table.getQualifiedName() + " drop constraint " + constraintName);
>
> ResultSet rs = ps.execute(lcc, true, 0L);
> rs.close();
> rs.finish();
> return;
>
> }
>
> This works fine as long as the user who issued the revoke references
> privilege is a dba or owner of the table on which foreign key constraint is
> defined. But for any other user, the revoke references privilege barfs
> saying that user can't perform the operation in that schema.
I would have exepected the ConstraintDescriptor to drop itself directly
using the DataDictionary apis, rather than go back through SQL. Would
that be possible?
Dan.
