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 03:01: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:
---------------------------------

    Description: 
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.")


  was:
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.")



> 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 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