Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1943404107.1205342926788.JavaMail.jira@brutus>
Date: Wed, 12 Mar 2008 10:28:46 -0700 (PDT)
From: "Kathey Marsden (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-3494) Move the setup of
 NormalizeResultSetNode into the NormalizeResultSetNode
In-Reply-To: <157586403.1204676020824.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

    Derby Info: [Patch Available]

> 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: d3494_npe_writeup.html, d3494_npe_writeup.html, decompile.out, derby-3494_remove_genNormalizeResultSetNode_diff.txt, 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.