You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mamta A. Satoor (JIRA)" <ji...@apache.org> on 2007/04/20 09:56:15 UTC
[jira] Created: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
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
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.
[jira] Assigned: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "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 reassigned DERBY-2569:
--------------------------------------
Assignee: Mamta A. Satoor
> 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_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.
[jira] Updated: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "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.
[jira] Commented: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490414 ]
Mamta A. Satoor commented on DERBY-2569:
----------------------------------------
Looking at the existing comparable code in various implementations of TypeCompiler, it seems that all the types(except for Ref, XML, CLOB, BLOB) are comparable to user types. I will go ahead and add/modify comment regarding this in DTD.comparable.
I though switch was better in terms of code readability for the base types. The if statements at the beginning of the method are to cover big umbrella checks like no comparison involving CLOB, BLOB, Ref and java classes types. I won't mind changing it to one style if that seems better,
Yes, returning false will be th better thing to do. I will go ahead and change that.
> 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_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.
[jira] Updated: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "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:
-----------------------------------
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.
[jira] Commented: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490405 ]
Daniel John Debrunner commented on DERBY-2569:
----------------------------------------------
In the v2 patch some of the comments do not match the code, e.g. for TIME and TIMESTAMP compare checks in DTD.comparable(). They say the type is comparable to user types, but the code checks for character types.
In DTD.comparable() any reason for the switch in checking which type group the current type is?
The first 1/3 of the method uses the isXXXType() methods which seem more readable to me, but the remainder performs the checks using a switch statement on the jdbc type identifier.
The return "true" at the end of the method is dubious, would a "fail-safe" of return false be better? So that if a new type is added in the future
it doesn't become comparable to all other types automatically?
> 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_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.
[jira] Updated: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "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:
-----------------------------------
Attachment: DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v3_stat.txt
DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v3_diff.txt
Commited patch DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v3_diff.txt using revision 530910 with following commit comments
DERBY-2569 Basically, this commit moves the logic for comparable method from various TypeCompiler implementations into DTD. This is because now we need collation information also to determine if 2 types are comparable or not and that information is not available to TypeCompilers. In addition, ofcourse, all the callers of TypeCompiler's comparable method now call DTD.comparable.
> 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_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.
[jira] Updated: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "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: [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_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.
[jira] Updated: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "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:
-----------------------------------
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.
[jira] Updated: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "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:
-----------------------------------
Attachment: DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v1_stat.txt
DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v1_diff.txt
I am attaching a patch DERBY2569_Move_comparable_From_TypeCompiler_To_DTD_v1_diff.txt which is NOT ready for commit because I am still running the tests but I wanted to put it out in case someone has time to review the changes. Basically, this patch moves the logic for comparable method from various TypeCompiler implementations into DTD. This is because now we need collation information to determine if 2 types are comparable or not and that information is not available to TypeCompilers. In addition, ofcourse, all the callers of TypeCompiler's comparable method now call DTD.comparable.
Would greatly appreciate any feedback.
> 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
>
>
> 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.
[jira] Commented: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490428 ]
Mamta A. Satoor commented on DERBY-2569:
----------------------------------------
Thinking more about it, may be it will be better to not look for individual format id in switch statement because that would mean, in future, when say another numeric type is added, we will have to modify the switch statement to look for that new numeric type. Instead, if I check for isXXX() method, then this code won't have to be maintained for new types that fall into existing isXXX() umbrella. I will go ahead and commit what I have now(changes from _v2_ patch : with more comments and method returning false at the end rather than true) in another hr or so and then change the code to use isXXX and check that as subsequent patch.
> 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_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.
[jira] Closed: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "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 closed DERBY-2569.
----------------------------------
> 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.
[jira] Resolved: (DERBY-2569) The check to see if two
DataTypeDescriptors(DTDs) are comparable or not needs to consider collation
into decision.
Posted by "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 resolved DERBY-2569.
------------------------------------
Resolution: Fixed
> 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.