[
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
