db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3494) Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode
Date Wed, 05 Mar 2008 22:45:40 GMT

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

Kathey Marsden updated DERBY-3494:
----------------------------------

    Attachment: decompile.out
                npe.sql

I am  trying to understand why we get the npe in views.sql with the small code change proposed
at: https://issues.apache.org/jira/browse/DERBY-3310?focusedCommentId=12575071#action_12575071

I am not having too much luck debugging this. I am attaching the script npe.sql which is a
smaller script than views.sql to reproduce the problem, and also decompile.out which decompiles
the generated code.

Any tips on debugging this would be greatly appreciated.  One thing I did look at was the
difference between prRCList and resultColumns after the copy. There was some state that didn't
get copied, and I tried copying that state, including the LCC.  That did not have any effect
and I still got the NPE.

As an aside there is this interesting comment in UnionNode. I don't know if it comes into
play here but seemed notable.

		/* RESOLVE - We'd like to generate any necessary NormalizeResultSets
		 * above our children here, in the tree.  However, doing so causes
		 * the following query to fail because the where clause goes against
		 * the NRS instead of the Union:
		 *		SELECT TABLE_TYPE
		 *		FROM SYS.SYSTABLES, 
		 *			(VALUES ('T','TABLE') ,
		 *				('S','SYSTEM TABLE') , ('V', 'VIEW')) T(TTABBREV,TABLE_TYPE) 
		 *		WHERE TTABBREV=TABLETYPE;
		 * Thus, we are forced to skip over generating the nodes in the tree
		 * and directly generate the execution time code in generate() instead.
		 * This solves the problem for some unknown reason.
		 */


Thanks again for any pointers.


> Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode
> ------------------------------------------------------------------------
>
>                 Key: DERBY-3494
>                 URL: https://issues.apache.org/jira/browse/DERBY-3494
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 10.4.0.0
>            Reporter: Kathey Marsden
>            Priority: Minor
>         Attachments: decompile.out, npe.sql
>
>
> In DERBY-3310 Dan suggested ...
> Setting up a NormalizeResultSetNode is spread over three locations, the class itself
(very little, it's almost acting like a C struct),
> the genNormalizeResultSetNode method and then copyLengthsAndTypesToSource. A good O-O
implementation would have
> the logic to create a NormalizeResultSetNode self-contained in NormalizeResultSetNode.
> Since the ResultColumnList of the original ResultSetNode correctly describes the desired
outcome, it's not clear to
> me why NormalizeResultSetNode can't just refer to the same list and use it for its processing.
They may be some chance
> that this would cause recursion at some point, where a NormalizeResultSetNode would think
it needed to be wrapped
> in a NormalizeResultSetNode since the types of its columns and expression don't match
(i.e. when it is handled as a regular ResultSetNode).
> I think moving the setup of a NormalizeResultSetNode into the class itself, so that its
inputs are just the ResultSetNode to wrap
> would help clear up the code, especially if comments were added indicating why certain
actions were being taken.
> I am separating this task out into a separate issue, so that it can be worked on independently
of DERBY-3310.

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