[jira] Updated: (DERBY-2569) The check to see if two DataTypeDescriptors(DTDs) are comparable or not needs to consider collation into decision.

["Mamta A. Satoor (JIRA)" <ji...@apache.org>]

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

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

    Derby Info:   (was: [Patch Available])

> 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
>         Assigned To: Mamta A. Satoor
>         Attachments: DERBY2569_change_formatid_checks_to_isXXX_checks_v1_diff.txt, DERBY2569_change_formatid_checks_to_isXXX_checks_v1_stat.txt, 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, DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v3_diff.txt, DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v3_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.