[MDEV-16852] Get rid of Item_temporal_hybrid_func::fix_temporal_type() - Jira

Alexander Barkov created issue - 2018-07-30 12:02

Alexander Barkov made changes - 2018-07-30 12:03

Field	Original Value	New Value
Link		This issue blocks MDEV-15750 [ MDEV-15750 ]

Alexander Barkov made changes - 2018-07-30 12:04

Description

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.

We'll remove this method and change val_str_ascii() as follows:

{code:cpp
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead, of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this switch{} itself can be moved to Type_handler easy.

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add duplicate code in the per-data-type code branches.

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.

We'll remove this method and change val_str_ascii() as follows:

{code:cpp}
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead, of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this switch{} itself can be moved to Type_handler easy.

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add duplicate code in the per-data-type code branches.

Alexander Barkov made changes - 2018-07-30 12:08

Description

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.

We'll remove this method and change val_str_ascii() as follows:

{code:cpp}
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead, of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this switch{} itself can be moved to Type_handler easy.

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add duplicate code in the per-data-type code branches.

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.
Soon we'll need to support new data types for ADDTIME() and DATEADD() (see MDEV-15750, MDEV-11829, MDEV-10018)

We'll remove this method and change val_str_ascii() as follows:

{code:cpp}
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead, of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this switch{} itself can be moved to Type_handler easy.

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add duplicate code in the per-data-type code branches.

Alexander Barkov made changes - 2018-07-30 12:08

Link

This issue blocks ~~MDEV-4912~~ [ ~~MDEV-4912~~ ]

Alexander Barkov made changes - 2018-07-30 12:08

Link

This issue blocks MDEV-11829 [ MDEV-11829 ]

Alexander Barkov made changes - 2018-07-30 12:09

Link

This issue blocks MDEV-10018 [ MDEV-10018 ]

Alexander Barkov made changes - 2018-07-30 12:19

Description

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.
Soon we'll need to support new data types for ADDTIME() and DATEADD() (see MDEV-15750, MDEV-11829, MDEV-10018)

We'll remove this method and change val_str_ascii() as follows:

{code:cpp}
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead, of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this switch{} itself can be moved to Type_handler easy.

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add duplicate code in the per-data-type code branches.

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.
Soon we'll need to support new data types for ADDTIME() and DATEADD() (see MDEV-15750, MDEV-11829, MDEV-10018)

We'll remove this method and change val_str_ascii() as follows:

{code:cpp}
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead, of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this switch{} itself can be moved to Type_handler easy.

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add too much duplicate code in the per-data-type code branches.

Alexander Barkov made changes - 2018-07-30 16:37

Description

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.
Soon we'll need to support new data types for ADDTIME() and DATEADD() (see MDEV-15750, MDEV-11829, MDEV-10018)

We'll remove this method and change val_str_ascii() as follows:

{code:cpp}
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead, of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this switch{} itself can be moved to Type_handler easy.

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add too much duplicate code in the per-data-type code branches.

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.
Soon we'll need to support new data types for ADDTIME() and DATEADD() (see MDEV-15750, MDEV-11829, MDEV-10018)

We'll remove this method and change val_str_ascii() as follows:

{code:cpp}
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this switch{} itself can be moved to Type_handler easy.

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add too much duplicate code in the per-data-type code branches.

Alexander Barkov made changes - 2018-07-30 16:38

Description

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.
Soon we'll need to support new data types for ADDTIME() and DATEADD() (see MDEV-15750, MDEV-11829, MDEV-10018)

We'll remove this method and change val_str_ascii() as follows:

{code:cpp}
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this switch{} itself can be moved to Type_handler easy.

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add too much duplicate code in the per-data-type code branches.

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.
Soon we'll need to support new data types for ADDTIME() and DATEADD() (see MDEV-15750, MDEV-11829, MDEV-10018)

We'll remove this method and change val_str_ascii() as follows:

{code:cpp}
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this {{switch(field_type)}} itself can be moved to Type_handler easy (under terms of a separate task).

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add too much duplicate code in the per-data-type code branches.

Alexander Barkov made changes - 2018-07-30 16:39

Description

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.
Soon we'll need to support new data types for ADDTIME() and DATEADD() (see MDEV-15750, MDEV-11829, MDEV-10018)

We'll remove this method and change val_str_ascii() as follows:

{code:cpp}
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this {{switch(field_type)}} itself can be moved to Type_handler easy (under terms of a separate task).

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add too much duplicate code in the per-data-type code branches.

The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.
Soon we'll need to support new data types for ADDTIME() and DATEADD() (see MDEV-15750, MDEV-11829, MDEV-10018)

We'll remove this method and change val_str_ascii() as follows:

{code:cpp}
String *Item_temporal_hybrid_func::val_str_ascii(String *str)
{
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;

- if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||
+ if (get_date(&ltime, 0) ||
       (null_value= my_TIME_to_str(&ltime, str, decimals)))
     return (String *) 0;
{code}

Instead of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

{code:cpp}
  switch (field_type()) {
  case MYSQL_TYPE_TIME:
    // the code to process TIME
    return ...;
  case MYSQL_TYPE_DATE:
    // the code to process DATE
    return ...
  case MYSQL_TYPE_DATETIME:
    // the code to process DATETIME
    return ...;
  default:
    // the code to process non-temporal return type
    return ...;
  }
{code}

So later this {{switch(field_type)}} itself can be moved to Type_handler easy (under terms of a separate task).

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The list of affected descendant classes:
- Item_date_add_interval
- Item_func_add_time
- Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add too much duplicate code in the per-data-type code branches.

Alexander Barkov made changes - 2018-07-30 16:56

issue.field.resolutiondate

2018-07-30 16:56:05.0

2018-07-30 16:56:05.125

Alexander Barkov made changes - 2018-07-30 16:56

Fix Version/s		10.4.0 [ 23115 ]
Fix Version/s	10.4 [ 22408 ]
Resolution		Fixed [ 1 ]
Status	Open [ 1 ]	Closed [ 6 ]

Sergei Golubchik made changes - 2021-12-06 21:23

Workflow

MariaDB v3 [ 88643 ]

MariaDB v4 [ 133638 ]

MariaDB Server

Get rid of Item_temporal_hybrid_func::fix_temporal_type()

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration