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