db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5747) Native user authentication: Docs do not describe what happens to schema and its SQL objects on SYSCS_UTIL.SYSCS_DROP_USER call
Date Tue, 08 May 2012 12:31:51 GMT

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

Dag H. Wanvik commented on DERBY-5747:
--------------------------------------

I agree 1) is a valid use case, although I'd probably prefer something like DISABLE_USER for
such a functionality. Understood, a cascading delete is non-trivial. Options: introduce an
extra argument to DROP_:USER(<user>, <mode>) where <mode> could be CASCADE
later, or for now, KEEP to let schema(s) owned by the user hang around. A new ALTER SCHEMA
could be used for that purpose later. 
I think the new mechanism should be viewed as *more* than just adding and dropping passwords,
although that's mainly what the current code does in n addition to introducing a user auth
id repository. But I think we should try to design this in such a way that we can extend the
functionality in a later increment to encompass management of users in a broader sense. If
so, I think we should retain the syntax CREATE_USER..
                
> Native user authentication: Docs do not describe what happens to schema and its SQL objects
on SYSCS_UTIL.SYSCS_DROP_USER call
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5747
>                 URL: https://issues.apache.org/jira/browse/DERBY-5747
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation, Services
>    Affects Versions: 10.9.0.0
>            Reporter: Dag H. Wanvik
>            Assignee: Kim Haase
>         Attachments: repro2.sh
>
>
> Currently, the schema and the objects remain after the user is dropped, cf. repro2.sh
attached.
> The authorization id of the schema of the dropped user is still that id (dangling) after
DROP.
> Perhaps ownership should revert to the DBO when a user is dropped, or should DROP USER
do a cascade delete?
> There is no way currently to change the ownership of the schema to another user.
> At the very least we should document what happens.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message