db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
Date Sun, 24 Feb 2008 19:07:14 GMT

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


Mime
View raw message