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] Commented: (DERBY-3270) Delayed (on-demand) creation of current user schema makes select from view belonging to other schema fail.
Date Thu, 20 Nov 2008 17:54:44 GMT

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

Dag H. Wanvik commented on DERBY-3270:
--------------------------------------

What seems to be the problem is the following. The column reference
(A; expanded from *) is attempted bound against the table MYTABLE
twice inside FromBaseTable#getMatchingColumn: 

First, when the view is created. At this time the current compilation
schema is JOE and there is no problem.

Second, the SELECT is bound, the view is expanded to a subquery (under
DMLStatementNode#bind's call to bindTables->bindNonVTITables, parsed
and table reference bound using the original schema, see comment in
that method), and then later the expressions are bound under
DMLStatementNode#bind's call to bindExpressions. This time the
compilation schema is reset to BILL, however. 
In FromBaseTable#getMatchingColumn, the call:

  columnsTableName.bind(this.getDataDictionary());

tries to bind the unqualified table name (MYTABLE) and finds the current schema
BILL. If BILL already exists, this goes well, if not, we see
DERBY-3270. Now, if this is bound incorrectly, why does it work? It
seems this binding is inconsequential, in that columnsTableName is a
local variable, and if we follow the logic in getMatchingColumn after
the binding, we see that the matching happens with this call:

  if (columnsTableName == null || columnsTableName.equals(exposedTableName))
  {
     resultColumn = resultColumns.getResultColumn(columnReference.getColumnName());

exposedTableName has the same (wrong) binding, derived from
FromTable#origTableName, so the equals test works. Next, we basically
just checks if "A" is present in resultColumns. resultColumns is
correct since the table was bound correctly already.

I am not sure what the right fix is here, though. It would appear that
binding schema incorrectly as done in getMatchingColumn (and for origTableName) 
is not good, and the first patch doesn't address that. 

Maybe we could note the original compilation schema in the root of the view subquery
subsituted from the view name in the original query and find that
(walking up the tree) when the current default schema is looked up
somehow?


> Delayed (on-demand) creation of current user schema makes select from view belonging
to other schema fail.
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3270
>                 URL: https://issues.apache.org/jira/browse/DERBY-3270
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.1.4
>            Reporter: Dag H. Wanvik
>            Assignee: Kathey Marsden
>            Priority: Minor
>         Attachments: derby-3270_diff.txt, Main.java
>
>
> The enclosed repro fails with error 42Y07 'Schema BILL does not exist', even though
> the query does not reference that schema; it selects from joe.myview.

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