db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3897) SQLSessionContext not correctly initialized in some non-method call nested contexts
Date Wed, 08 Oct 2008 20:19:44 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638061#action_12638061
] 

Rick Hillegas commented on DERBY-3897:
--------------------------------------

Thanks for the patch, Dag. I think that there are 2 things going on in this patch: 1) some
routines have been renamed in order to clarify that nested contexts can be created by situations
other than CALL statements and 2) there's a fix to a context stacking bug. I had a hard time
finding the code for (2) because there is so much code associated with (1). It might be nice
if some header comment listed the situations which give rise to nested contexts (as you do
in your patch comment). Thanks. 

> SQLSessionContext not correctly initialized in some non-method call nested contexts
> -----------------------------------------------------------------------------------
>
>                 Key: DERBY-3897
>                 URL: https://issues.apache.org/jira/browse/DERBY-3897
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.5.0.0
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>             Fix For: 10.5.0.0
>
>         Attachments: derby-3897-1.diff, derby-3897-1.stat, derby-3897-repro.diff
>
>
> In some contexts, beside calling stored routines containing SQL, Derby
> uses nested execution contexts, wehere we have two nested activations,
> but no nested connections.
> In such cases, currently a new SQLSessionContext is constructed, but
> not initialized correctly.  This leads to the session variables
> CURRENT_ROLE/CURRENT_SCHEMA not being set correctly in these contexts
> (they should inherited from the parent context, cf DERBY-3327).
> For method calls, this is being handled by generating a call to
> lcc.setupNestedSessionContext (see
> StaticMethodCallNode#generateSetupNestedSessionContext)
> In some of these nested contexts, one or both of the session variables
> CURRENT_ROLE/CURRENT_SCHEMA can be referenced, in others
> not. Obviously, if they can, this will lead to errors. The following
> contexts will have this problem:
> - ALTER TABLE ADD COLUMN <colname> <coltype> DEFAULT CURRENT_ROLE
>   In the AlterTableConstantAction, a nested UPDATE statement is used
>   to give existing rows the new column its default value. This
>   execution context is nested, cf. AlterTableConstantAction#executeUpdate
> - TRIGGER body execution may reference CURRENT_ROLE/CURRENT_SCHEMA.
>   The body executes in a nested context,
>   cf. GenericTriggerExecutor#executeSPS.
> In other cases, the session variables can not be referenced, so this
> not a problem: 
> - CHECK constraint execution
> - EmbedResultSet.insertRow, .deleteRow, .updateRow
> The session context should not be changed (pushed) for these nested
> executions, since there is no nested connection (SQL 2003, 4.37.1: "An
> SQL-session is associated with an SQL-connection.")

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message