db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3897) SQLSessionContext not correctly initialized in some non-method call nested contexts
Date Thu, 09 Oct 2008 16:50:44 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dag H. Wanvik updated DERBY-3897:
---------------------------------

    Attachment: derby-3897-2.stat
                derby-3897-2.diff

Uploading revision #2 of this patch, which adds a test case for the following case: ALTER
TABLE adds a CHECK constraint that calls a  user defined function with a nested connection,
to test that the substatement used by alter table to do the checking of existing rows in the
table w.r.t the new check constraint, gets the correct session context, which is in turn inherited
when the session context is pushed to the user defined function.

(code snip):

In this case, the session context stack contains two elements referenced from the three activations
thus:

top level "ALTER TABLE" activation          -> top level session context
substatement (CHECK CONSTRAINT activation)  -> top level session context
nested connection in getCurrentRole,
           "VALUES CURRENT_ROLE" activation -> pushed session context

Regressions ran cleanly and I verified that the new test case fails without the patch.

> 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-2.diff, derby-3897-2.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 when executed as part of an ALTER TABLE
> - 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