db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: advice sought: introduction of new system table on trunk
Date Fri, 09 Nov 2007 14:56:51 GMT
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.


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

View raw message