You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dag H. Wanvik" <Da...@Sun.COM> on 2007/11/09 15:26:02 UTC
advice sought: introduction of new system table on trunk
In the roles work I am introducing a new catalog, SYS.SYSROLES.
I am considering impacts of committing new the code to trunk and would
appreciate some advice.
- In the event that the roles feature is not ready for 10.4, it would
need to be backed out, which could cause some turbulence in a
release end-game. Is this an acceptable risk, or should a new
feature which introduces a new catalog be on its own branch until it
is ready (with the ensuing merge pains) ?
I would prefer to stay on trunk, but realize there is a potential
downside if the feature is not ready in time..
- When committing the patch for DERBY-3137, until I include hard
upgrade code to add the new catalogue, an upgraded database will
lack the new catalog and fail whenever a role related statement or
expression is used ERROR XSAI2: The conglomerate (-1) requested does
not exist. Some tests which are sensitive to the number of catalogs
would also fail when run against an upgraded database for the same
reason.
In the spirit of incremental development, is it OK to check in the
new catalog code (hard upgrade doesn't break; it just doesn't do all
it is supposed to do yet), or should I wait until I have a patch
that handles the upgrade as well?
Thanks,
Dag
Re: advice sought: introduction of new system table on trunk
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Dag,
Here's my $.02: I think that there is plenty of precedent for checking
in partial features. There is even precedent for removing unfinished
features before cutting the release branch. I suspect that your upgrade
code will be checked in long before Bernt builds the 10.4
release--that's at least 2 months out. If the Roles work is not
done--and we decide that we want to go ahead with 10.4 anyway--then I
think we can get away with the following:
1) Leave the catalog changes in. That means that a hard-upgrade will add
the new system table and its indexes even though they won't be used.
2) Disable role creation in the parser.
3) Disable the roles tests.
4) If you don't submit user documentation until the feature is complete,
then there shouldn't be any need to back out documentation changes.
That sounds like a small amount of back-out work to me and the
destabilization risk seems minimal. So I say
a) +1 to incremental development
b) Check in what you've got now and move on to the next increment.
Cheers,
-Rick
Dag H. Wanvik wrote:
> In the roles work I am introducing a new catalog, SYS.SYSROLES.
> I am considering impacts of committing new the code to trunk and would
> appreciate some advice.
>
> - In the event that the roles feature is not ready for 10.4, it would
> need to be backed out, which could cause some turbulence in a
> release end-game. Is this an acceptable risk, or should a new
> feature which introduces a new catalog be on its own branch until it
> is ready (with the ensuing merge pains) ?
>
> I would prefer to stay on trunk, but realize there is a potential
> downside if the feature is not ready in time..
>
> - When committing the patch for DERBY-3137, until I include hard
> upgrade code to add the new catalogue, an upgraded database will
> lack the new catalog and fail whenever a role related statement or
> expression is used ERROR XSAI2: The conglomerate (-1) requested does
> not exist. Some tests which are sensitive to the number of catalogs
> would also fail when run against an upgraded database for the same
> reason.
>
> In the spirit of incremental development, is it OK to check in the
> new catalog code (hard upgrade doesn't break; it just doesn't do all
> it is supposed to do yet), or should I wait until I have a patch
> that handles the upgrade as well?
>
> Thanks,
> Dag
>
>
Re: advice sought: introduction of new system table on trunk
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi,
Kristian Waagan <Kr...@Sun.COM> writes:
> INCITS/ISO/IEC 9075-11-2003
> Information technology - Database languages - SQL - Part 11:
> Information and Definition Schemas (SQL/Schemata)
>
> Seems the tables/views are defined by SQL queries, so it should be
> reasonably easy to do a quick first assessment of whether we have the
> required information handy or not.
Good question! I have checked, and I believe the proposed catalog
patch (DERBY-3137) contains what's needed, cf. section 6.34
ROLE_AUTHORIZATION_DESCRIPTORS base table of 9075-11-2003:
(quote):
CREATE TABLE ROLE_AUTHORIZATION_DESCRIPTORS (
ROLE_NAME INFORMATION_SCHEMA.SQL_IDENTIFIER,
GRANTEE INFORMATION_SCHEMA.SQL_IDENTIFIER,
GRANTOR INFORMATION_SCHEMA.SQL_IDENTIFIER,
IS_GRANTABLE INFORMATION_SCHEMA.CHARACTER_DATA
CONSTRAINT ROLE_AUTHORIZATION_DESCRIPTORS_IS_GRANTABLE_CHECK
CHECK ( IS_GRANTABLE IN ( 'YES', 'NO' ) ),
CONSTRAINT ROLE_AUTHORIZATION_DESCRIPTORS_PRIMARY_KEY
PRIMARY KEY ( ROLE_NAME, GRANTEE ),
CONSTRAINT ROLE_AUTHORIZATION_DESCRIPTORS_CHECK_ROLE_NAME
CHECK ( ROLE_NAME IN ( SELECT AUTHORIZATION_NAME
FROM AUTHORIZATIONS
WHERE AUTHORIZATION_TYPE = 'ROLE' ) ),
CONSTRAINT ROLE_AUTHORIZATION_DESCRIPTORS_FOREIGN_KEY_AUTHORIZATIONS_GRANTOR
FOREIGN KEY ( GRANTOR )
REFERENCES AUTHORIZATIONS,
CONSTRAINT ROLE_AUTHORIZATION_DESCRIPTORS_FOREIGN_KEY_AUTHORIZATIONS_GRANTEE
FOREIGN KEY ( GRANTEE )
REFERENCES AUTHORIZATIONS
)
SYS.SYSROLES (see below) has merged in the role definitions, though,
by adding an extra column ISDEF in lieu of the AUTHORIZATIONS table of
9075-11-2003, since there is no catalog today for valid Derby users
either. The definition always give rise to a role grant (to the
definer, dbo in our case), and that role grant carries the 'true'
value in the ISDEF column, thus serving also to identify the role
definitions.
If we later to decide add a catalog assembling users and roles
(probably a good idea), I think the present design does not preclude
that; the ISDEF column could then be just fall out of use.
The present catalog code patch maintains the constraints
shown, too.
SYSROLES presently has these columns:
ROLEID
GRANTEE
GRANTOR
WITHADMINOPTION
ISDEF
the four first of which map directly to TABLE ROLE_AUTHORIZATION_DESCRIPTORS.
Btw, wish we had those nice recursive views show, e.g. in ENABLED_ROLES.
Thanks,
Dag
Re: advice sought: introduction of new system table on trunk
Posted by Kristian Waagan <Kr...@Sun.COM>.
Dag H. Wanvik wrote:
> In the roles work I am introducing a new catalog, SYS.SYSROLES.
> I am considering impacts of committing new the code to trunk and would
> appreciate some advice.
>
> - In the event that the roles feature is not ready for 10.4, it would
> need to be backed out, which could cause some turbulence in a
> release end-game. Is this an acceptable risk, or should a new
> feature which introduces a new catalog be on its own branch until it
> is ready (with the ensuing merge pains) ?
>
> I would prefer to stay on trunk, but realize there is a potential
> downside if the feature is not ready in time..
>
> - When committing the patch for DERBY-3137, until I include hard
> upgrade code to add the new catalogue, an upgraded database will
> lack the new catalog and fail whenever a role related statement or
> expression is used ERROR XSAI2: The conglomerate (-1) requested does
> not exist. Some tests which are sensitive to the number of catalogs
> would also fail when run against an upgraded database for the same
> reason.
>
> In the spirit of incremental development, is it OK to check in the
> new catalog code (hard upgrade doesn't break; it just doesn't do all
> it is supposed to do yet), or should I wait until I have a patch
> that handles the upgrade as well?
Hello Dag,
A bit on the sideline of your request, but do you know if your system
table(s) fulfill the requirements specified by the SQL standard for
"Definition and Information Schemas"?
I just thought it could be good to think a little about it, so we can
choose to implement the Information Schema at a later time.
The "standards business" is a bit mysterious to me, but the document I
refer to should be uniquely identified by this:
INCITS/ISO/IEC 9075-11-2003
Information technology - Database languages - SQL - Part 11: Information
and Definition Schemas (SQL/Schemata)
Seems the tables/views are defined by SQL queries, so it should be
reasonably easy to do a quick first assessment of whether we have the
required information handy or not.
regards,
--
Kristian
>
> Thanks,
> Dag
>