Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Wed, 30 May 2007 16:39:11 +0200
From: Dag.Wanvik@Sun.COM (Dag H. Wanvik)
Subject: Re: 10.3 blocker issue - DERBY-2728
In-reply-to: <c25576af0705292055x14baaec7p2cf3217071b57c09@mail.gmail.com>
Sender: Dag.Wanvik@Sun.COM
To: derby-dev@db.apache.org
Message-id: <x1oxfy5el6k0.fsf@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <c25576af0705292055x14baaec7p2cf3217071b57c09@mail.gmail.com>
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.0.50 (usg-unix-v)

Myrna van Lunteren <m.v.lunteren@gmail.com> writes:

> Hi,
>
> We have a bump in our 10.3 release path - DERBY-2728.
>
> I'd like the opinion of the community as to how we can address this;
> how long would a fix take (and thus delay a release); who would be
> willing to implement a fix?

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?
>
> Please give your 2 (or other #) cents.
>
> Regards,
> Myrna
>

-- 
Dag H. Wanvik
Sun Microsystems, Database Technology Group (DBTG)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101