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] Updated: (DERBY-3877) SQL roles: build support for dblook
Date Fri, 26 Sep 2008 00:51:44 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dag H. Wanvik updated DERBY-3877:

    Attachment: derby-3877-2.stat

Uploading revision 2 of this patch. It

- closes the result set Rick pointed to
- adds code in the harness files RunTest.java and NetServer.java
  to be able to shut down the server cleanly. It needs user/password with the
  modified dblook test which runs with authorization on. I noticed that net version of test
  when shutting down. The server process stopped eventually on timeout though, so it did work
  in the previous revision, but it seems cleaner to add this fix. And it saves test clock
  Hopefully we can move the dblook test to JUnit sometime soon.

I ran dblook_test[_territory].java, dblook_test_net[_territory] individually as well as derbynetclientmats
Running entire regression over again now.

> SQL roles: build support for dblook
> -----------------------------------
>                 Key: DERBY-3877
>                 URL: https://issues.apache.org/jira/browse/DERBY-3877
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Tools
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>             Fix For:
>         Attachments: derby-3877-1.diff, derby-3877-1.stat, derby-3877-2.diff, derby-3877-2.stat
> dblook does have support for grant/revoke although I am unsure of its quality, cf, my
> in DERBY-3868. Nevertheless, I choose to build support for roles for dblook.
> Since role creation and the granting of roles is only allowed for the data base owner
in the first basic
> roles implementation, expanding the existing dblook tests to just dump the roles and
roles grants should be easy.
> In general though, the dblook output file, in order to receate a database, must potentially
use several connection, so the objects will be owned by the original owner. [The model for
running the presently generated script run seems to be within one connection.] Setting roles
properly to be able to recreate a view with the correct owner, for example, would be part
of such a more advanced script which would be object owner aware.
> My intention with this issue is just to add support for dumping roles and role grants.

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

View raw message