Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <32475945.1177058655447.JavaMail.jira@brutus>
Date: Fri, 20 Apr 2007 01:44:15 -0700 (PDT)
From: "Mamta A. Satoor (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-2569) The check to see if two
 DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
 into decision.
In-Reply-To: <9794639.1177055775626.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-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mamta A. Satoor updated DERBY-2569:
-----------------------------------

    Attachment: DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v2_stat.txt
                DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v2_diff.txt

Please disregard the _v1_ patch. Instead, I have attached DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v2_diff.txt In the earlier patch, I was not returning false in DTD.comparable method for character types if we were not comparing them with date/time/timestamp/boolean or another character type. Have fixed that in _v2_ and have restarted the tests

> The check to see if two DataTypeDescriptors(DTDs) are comparable or not needs to consider collation into decision.
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2569
>                 URL: https://issues.apache.org/jira/browse/DERBY-2569
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions: 10.3.0.0
>            Reporter: Mamta A. Satoor
>         Attachments: DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v1_diff.txt, DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v1_stat.txt, DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v2_diff.txt, DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v2_stat.txt
>
>
> Currently, when Derby needs to check if 2 DTDs are comparable or not, it calls TypeCompiler.comparable method. This method now has to move to DTD because we should consider collation information while deciding if 2 DTDs are comparable or not. That collation information is not available to TypeCompiler but it is available at DTD level. More information on this can be found at http://www.nabble.com/Re%3A-Changes-to-comparable-method-in-TypeCompiler-tf3603373.html#a10089238. Some of the important info from the thread is copied below
> > I think what you are suggesting is to move comparable method out from 
> > the TypeCompiler and into DataTypeDescriptor altogether. So, the 
> > existing code, where we use TypeCompiler to decide if 2 types can be 
> > compared or not should now call a method on DTD to determine 
> > comparability. This might be cleaner than stuffing collation information 
> > in CharTypeCompiler but I am just wondering why was comparable not 
> > defined on DTD at the very start. Why do we go through TypeCompiler and 
> > what functionality does TypeCompiler provide that DTD does not? In other 
> > words, I don't understand the connection between TypeCompiler and DTD 
> > and how they fit together. 
> It's not that TypeCompiler provides functionality that DTD does not, but 
> instead DTD has functionality/information that TypeCompiler does not. 
> Ignoring the "compiler" aspect for the moment there are two components 
> to a DataTypeDescriptor, the underlying SQL type (INTEGER, CHAR, 
> VARCHAR, XML etc.) represented as TypeId and attributes of the 
> descriptor (nullablity, length, precision, scale and now collation). 
> Thus 
>   DTD = TypeId + {attributes} 
> Some functionality is applicable to a type regardless of a specific 
> DTD's attributes, thus methods for that functionality can be declared on 
> TypeId instead of DTD. 
> Some functionality on the other hand needs the attribute information as 
> well, say the display length of a type is a function of its 
> length/precision&scale and its underlying SQL type. 
> The collation changes have moved the comparable check from being only 
> reliant on the SQL type (TypeId) to being dependent on the type's 
> attributes (collation type and implicit/explicit). Thus the original 
> location for the comparable method made sense, but now does not. 
> The TypeCompiler/TypeId split was due to an early plan to have a 
> execute-only version of the technology, this never happened as there was 
> no demand for it. One of the benefits of a SQL engine is the ability to 
> execute arbitrary queries, which would not be available in an execute 
> only version. Code cleanup could be done here which probably would 
> decrease the footrprint of derby. 
> HTH, 
> Dan. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.