[
https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571929#action_12571929
]
Daniel John Debrunner commented on DERBY-3310:
----------------------------------------------
[yet more rambling]
A ResultSetNode has a set of ResultColumns and each ResultColumn has an
expression under it.
A NormalizeResultSetNode is added above a ResultSetNode (wraps it) when the
type of at least one of its
ResultColumn does not match the type of its expression,
ResultColumn indicates this can be the case & I added some more comments to
that.
Once the decision is made to add a NormalizeResultSetNode there is some
processing of ResultColumns and ResultColumnLists
that I haven't understood yet, this includes the call
copyLengthsAndTypesToSource() that Kathey modified.
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.
> ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
> ----------------------------------------------------------------------
>
> Key: DERBY-3310
> URL: https://issues.apache.org/jira/browse/DERBY-3310
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.4.0.0
> Reporter: Dyre Tjeldvoll
> Assignee: Kathey Marsden
> Priority: Minor
> Attachments: cast-repro.sql, derby-3310_try1_diff.txt,
> derby3310_rsn_cleanup_1.txt
>
>
> The following code
> CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT);
> -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT)
> INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2
> FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID;
> gives
> ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class
> org.apache.derby.iapi.types.SQLInteger) expected to be the same as
> col2.getClass() (class org.apache.derby.iapi.types.SQLLongint):
> org.apache.derby.shared.common.sanity.AssertFailure'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
