Dag H. Wanvik wrote:
Myrna van Lunteren <[EMAIL PROTECTED]> writes:
Hi,
We have a bump in our 10.3 release path - DERBY-2728.
= = = = SNIP = =====
If we choose to tie enforcement to SQLAuthorization being on, I think
this is a fairly small patch; the existing tests still have test cases
for this (authentication + SQLauthorization), so they could be tweaked
easily too. I expect most work would be to change the documentation
(DERBY-2520). The release note for DERBY-2264 would need to change as
well. I'd be willing to do this work if we choose that approach. I'd
need a week; generally pushing releases less than 2 weeks seems not
worth it, so I suggest a 2 week delay.
DERBY-2728 speaks about making the semantics optional a *upgrade
time*, though, which is another approach. This could imply some
persistence of the fact that the database was upgraded and should have
different semantics than a freshly created one, or use of extra
properties. If someone volunteers to make such a solution, thats fine
with me.
Note that even if we tie enforcement to SQLAuthorization, some
existing application may still be impacted, although presumably much
fewer applications, since this is a 10.2 feature, and already implies
a database owner concept and is probably less likely to be used in an
embedded context (Kathey's concern).
Thanks,
Dag
Should we make a release candidate while the fixing is in progress?
Hi -
Dag's suggestion seems like a best-approach to me. +1
It solves the problem with a 'fairly small patch' and can be done with
minimal impact on the release date. The change will allow people who
have not already set SQLAuthorization to test the impact of the new DBO
role on their system and opt out of implementing it at this time. As
Dag points out, people who have already stepped up to using
SQLAuthorization will have identified the DBO account and designed the
system accordingly so the change should be less dramatic.
As a side note I think it good to encourage Derby users to plan for and
implement the DBO role at their earliest convenience. Once the required
changes are made and tested the flag can be set and the system will have
the benefit of improved security.
And the question about:
Should we make a release candidate while the fixing is in progress?
This seems like extra work for the Release Manager so, unless someone is aware
of a critical need for a full release candidate build in the next week or two I
would hold off. Of course I am not the Release Manager and it is her call.
