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] Created: (DERBY-3494) Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode
Date Wed, 05 Mar 2008 00:13:40 GMT
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:
            Reporter: Kathey Marsden
            Priority: Minor

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.

View raw message