db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@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.
Date Thu, 26 Apr 2007 06:37:15 GMT

     [ 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_change_formatid_checks_to_isXXX_checks_v1_stat.txt
                DERBY2569_change_formatid_checks_to_isXXX_checks_v1_diff.txt

Committed patch DERBY2569_change_formatid_checks_to_isXXX_checks_v1_diff.txt with revision
532627. The patch is attached to this Jira entry for easy review if anyone is interested.

The commit comments were as follows
This is more of a code cleanup for DERBY-2569. 
Rather than using switch statement to check for individual format ids, this patch uses isXXX
methods wherever applicable to determine if two types are comparable or not. This is because
with format id checking, in future, when say another numeric type is added, we will have to
modify the switch statement to look for that new numeric type's format id. Instead, if we
check for isXXX() method, then the formatid checks won't have to be maintained because the
new numeric type will fall into existing isXXX() umbrella.  




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


Mime
View raw message