db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [Grant/Revoke]Proposal for invoker/definer model
Date Thu, 16 Mar 2006 14:00:08 GMT

Thanks for the answers, some more comments below.

Mamta Satoor wrote:

> Hi Dan,
> Here are answers to your questions
> Question 1)
> <quote>
> This paragraph talks about a stack of default schemas and current
> schemas, but there are no more details of how this will be implemented.
> Also, I don't remember anything in the functional spec about how current
> or default schema was changing, but I can't get to Jira to check & I
> don't have a local copy of the functional spec from DEBRY-464. Just want
> to understand what functionality you are proposing to be implemented.
> </quote>
> Let me take an example to explain what I am trying to achieve here. Have
> a insert trigger on a table and have the trigger invokes a function. The
> invoked function will change the schema to a different schema. What
> should be the current schema at the end of insert statement?
[example snipped]

It looks like you are proposing a functional change in the way that
schemas are handled, the example was helpful but it's not clear to me
what exactly you are defining the scope of a SET SCHEMA statement to be.
Is it only effective during a function, during a trigger or constraint,
a view? Is this change in behaviour only in sql authorization mode?

This would be good to be in the functional spec for 464 or a separate
writeup in the sub-task you are working on.

> Question 2)
> <quote>
> The etc. is a little worrying in a design spec, which methods are you
> changing the behaviour of, is LCC.getAuthorizationId one of them?
> </quote>
> LCC has various methods which at this point uses the session authorizer
> and it's schema. This was fine with legacy database. But with
> sqlStandard database, these methods should get the current authorizer
> from the top active StatementContext and use that authorizer and it's
> schema in the various methods. In the absence of an active
> StatementContext, LCC should use session authorizer. The reason behind
> this change is same as the answer to Question 1.
> The LCC methods affected will be
>  public PreparedStatement prepareInternalStatement(String sqlText) 
>  public String getAuthorizationId()
>  public SchemaDescriptor getDefaultSchema() 
>  public String getCurrentSchemaName()
>  public void setDefaultSchema(SchemaDescriptor sd)
>  public void setReadOnly(boolean on) throws StandardException
>  public boolean isReadOnly()
>  public Authorizer getAuthorizer()

Are the read-only changes due to another functional change that's not
defined? Is the scope of setting read-only to be changed? Some writeup
of how the functionality is changing for user applications would be great.

Why is prepareInternalStatement changing? Is this a list of
LanguageConnectionContext methods that are changing their contract, or
GenericLanguageConnectionContext methods that are changing their

These changing the effective user in sql authorization mode seems
somewhat tricky in the details, if not the overall concept. I'm just
trying to ensure we have a clear idea of what we want the behaviour as
seen by the application to be, since the details are not in the
functional spec.


View raw message