Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 36178 invoked from network); 24 Feb 2006 02:21:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 Feb 2006 02:21:31 -0000 Received: (qmail 47457 invoked by uid 500); 24 Feb 2006 02:21:30 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 47409 invoked by uid 500); 24 Feb 2006 02:21:30 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 47400 invoked by uid 99); 24 Feb 2006 02:21:29 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Feb 2006 18:21:29 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of msatoor@gmail.com designates 64.233.182.192 as permitted sender) Received: from [64.233.182.192] (HELO nproxy.gmail.com) (64.233.182.192) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Feb 2006 18:21:29 -0800 Received: by nproxy.gmail.com with SMTP id c31so144056nfb for ; Thu, 23 Feb 2006 18:21:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=FuT6u7SwrQUE5kPGd3UxVQ49aF5QyviIRtxoZvKZYqceVBmHNLoFMJjMM2U6/NIE9IzQDXlYQotMk12p5TdLMK/MISPkuSuEw/zhrXV8/FzodULFeS9nTlCoCuElOJtr2dJIeo18F57YIa29KwrFy4nhSlXVIXtCpBoZ/y0kihc= Received: by 10.49.33.10 with SMTP id l10mr2597138nfj; Thu, 23 Feb 2006 18:21:07 -0800 (PST) Received: by 10.49.22.19 with HTTP; Thu, 23 Feb 2006 18:21:07 -0800 (PST) Message-ID: Date: Thu, 23 Feb 2006 18:21:07 -0800 From: "Mamta Satoor" To: derby-dev@db.apache.org Subject: Re: Grant/Revoke subtask - EXTERNAL SECURITY DEFINER | EXTERNAL SECURITY INVOKER In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3220_25404014.1140747667749" References: <43FB8D6C.6060602@Sourcery.Org> <43FCAEAE.3040808@Sourcery.Org> <43FCB097.4080808@apache.org> <43FE4458.2070607@apache.org> <43FE4CBA.5010605@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_3220_25404014.1140747667749 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Based on pros and cons listed by Dan, it seems like it would be better to continue with the existing paradigm of RoutineAliasInfo for the new column. So, I will go ahead and make changes in my codeline to put invoker security info in RoutineAliasInfo. thanks, Mamta > On 2/23/06, Daniel John Debrunner wrote: > > > > Mamta Satoor wrote: > > > > > I chose to have a new column in SYSALISES rather than expanding > > > RoutineAliasInfo becasue, like Satheesh brought it up in his followin= g > > > > > comment below, metadata extraction won't be straightforward if it was > > > part of RoutineAliasInfo. > > > "It would become harder to extract this info from RoutineAliasInfo as > > it > > > is a Java object for any metadata processing... like in dblook or for > > > other GUI tools. We would have to document how RoutineAliasInfo gets > > > generated as a character type and maintain that format in the future.= " > > > > But that's the case today. The toString() output is used by dblook. Is > > there any specific requirement for the invoker security to be separate > > from the rest of the information stored in RoutineAliasInfo, when > > accessed through SQL? > > > > Seems like this to me: > > > > new column > > upgrade code > > dblook additional code > > > > RoutineAliasInfo > > no upgrade change > > no dblook change > > change self contained in RoutineAliasInfo > > > > I was planning at some point to add some other routine attributes to > > RoutineAliasInfo, just trying to understand why a change in existing > > paradigm is happening. > > > > Thanks, > > Dan. > > > > > > > ------=_Part_3220_25404014.1140747667749 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Based on pros and cons listed by Dan, it seems like it would be better= to continue with the existing paradigm of RoutineAliasInfo for the new col= umn. So, I will go ahead and make changes in my codeline to put invoker sec= urity info in RoutineAliasInfo.
 
thanks,
Mamta

 
On 2/23/06, Daniel John Debrunner < djd@apache.org> wrote:
Mamta Satoor wrote:

> = I chose to have a new column in SYSALISES rather than expanding
> Rou= tineAliasInfo becasue, like Satheesh brought it up in his following=20
> comment below, metadata extraction won't be straightforward if it = was
> part of RoutineAliasInfo.
> "It would become harder = to extract this info from RoutineAliasInfo as it
> is a Java object f= or any metadata processing... like in dblook or for=20
> other GUI tools. We would have to document how RoutineAliasInfo ge= ts
> generated as a character type and maintain that format in the fu= ture."

But that's the case today. The toString() output is used= by dblook. Is=20
there any specific requirement for the invoker security to be separate<= br>from the rest of the information stored in RoutineAliasInfo, when
acc= essed through SQL?

Seems like this to me:

new column
 = ; upgrade code=20
  dblook additional code

RoutineAliasInfo
 &nb= sp;no upgrade change
  no dblook change
  change = self contained in RoutineAliasInfo

I was planning at some point to a= dd some other routine attributes to
RoutineAliasInfo, just trying to understand why a change in existing
par= adigm is happening.

Thanks,
Dan.


<= /div>


------=_Part_3220_25404014.1140747667749--