Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-15558

Save real data type in addition to existing data type



    • New Feature
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • Data types
    • None


      Saving "real" data type

      Data type are actually not the "real" data type, but "storage" data type.
      Storing an additional byte in frm files to save "real" data type information would solve lots of issues.

      BOOLEAN type means something compare to storage data type BIT(1) : that means Connector may return true/false and not 0/1.
      JSON type means that data is not just a string, but that string can be a parse to JSON object.

      Connectors actually don't know the "real" data type, and it's needed.
      Example with JSON: MySQL server save JSON field differently. The result is having a dedicated MYSQL_TYPE_JSON Data type that is sent to connectors.
      Connectors may then handle the data differently. The most popular javascript driver use that information to create a JSON object from the string.

      connection.query("insert into user(name, additional) value (?, ?)", ['john', {game:'myGame', level:23}]);
      connection.query("select from user", (err, rows) => {
      	//with mysql
              //rows[0] = {name:'john', additional: {game:'myGame', level:23}}
      	//with mariadb :
              //rows[0] = {name:'john', additional: "{game:'myGame', level:23}"}

      MariaDB saves JSON like a string, then connector has no information that this field is a JSON object.

      That additional byte would permit a lot of new functionalities: BOOLEAN, JSON ok, but that may permit new types like IPV4 / IPV6 / UUID that are store are text.

      Another minor annoyance is that SHOW CREATE could return initial type :

      CREATE TABLE `jsondata` (val1 JSON);
      SHOW CREATE TABLE `testj`.`jsondata`;
      //=> CREATE TABLE `jsondata` (
        `val1` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL
      //=> information about JSON is lost

      Possible non breaking change of protocol

      Current protocol for Column definition packet is :

      string<lenenc> catalog (always 'def')
      string<lenenc> schema
      string<lenenc> table alias
      string<lenenc> table
      string<lenenc> column alias
      string<lenenc> column
      int<lenenc> length of fixed fields (=0xC)
      int<2> character set number
      int<4> max. column size
      int<1> Field types
      int<2> Field detail flag
      int<1> decimals
      int<2> - unused -

      First field always send string<lenenc> catalog (always 'def') = 0x03 0x64 0x65 0x66
      no driver does use this information, because catalog doesn't exist in Mariadb.

      This field can be used to transmit to driver this additional metadata byte.
      This would permit that existing driver will receive the "storage" data type


        Issue Links



              bar Alexander Barkov
              diego dupin Diego Dupin
              3 Vote for this issue
              14 Start watching this issue



                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.