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

External ENUM Field definition

Details

    • Task
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • None
    • None
    • None

    Description

      Based in a table, KEY-VALUE, we could expand the ENUM field from limited size (65535 values) to a unlimited size (64bits), this is a new field type

      ENUM_EXTERNAL(database,table,key column,value column)

      the internal value of ENUM_EXTERNAL is a bigint, the string representation is a blob (or maybe a varchar(255) or a text)

      the point is:

      the storage engine will save a bitint
      the mysql core will convert the STRING to BIGINT using the database/table/key column/value, using a SELECT like this:

      SELECT <value_column> FROM <database>.<table> WHERE <value_column>="FIELD VALUE SEND VIA INSERT/UPDATE/DELETE"
      UNION
      SELECT <key_column> FROM <database>.<table> WHERE <key_column>="FIELD VALUE SEND VIA INSERT/UPDATE/DELETE"
      LIMIT 1

      this solve the problem of .FRM file don't allowing a big definition of ENUM/SET, and add an feature to developer of an avoid of alter table to change enum definition (it can use the external table to define the key-values of enum)

      Attachments

        Issue Links

          is blocked by

          Epic - Created by Jira Software - do not edit or delete. Issue type for a big user story that needs to be broken down. MDEV-4912 Data type plugin API version 1

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            pomyk Patryk Pomykalski added a comment -

            Why wouldn't you just use an int/bigint column and a dictionary table by yourself? Why complicate the server code?

            pomyk Patryk Pomykalski added a comment - Why wouldn't you just use an int/bigint column and a dictionary table by yourself? Why complicate the server code?
            rspadim roberto spadim added a comment -

            hi patryk,
            no problem to do this in a dictionary table, but i will do it when a field
            plugin could be used, the today implementation of enum use memory to solve
            the string -> number 'conversion', i want to use disk (storage engine) to
            do this
            yes it a developer/dba table design problem, but if it's possible could be
            nice implement it at server
            check the idea of https://mariadb.atlassian.net/browse/MDEV-4912

            i will make this one as blocked by mdev-4912, this will remove problems
            about 'complicate' the server code, the problem will be changed to 'plugin
            code'

            2013/8/17 Patryk Pomykalski (JIRA) <jira@mariadb.atlassian.net>

            –
            Roberto Spadim
            SPAEmpresarial

            rspadim roberto spadim added a comment - hi patryk, no problem to do this in a dictionary table, but i will do it when a field plugin could be used, the today implementation of enum use memory to solve the string -> number 'conversion', i want to use disk (storage engine) to do this yes it a developer/dba table design problem, but if it's possible could be nice implement it at server check the idea of https://mariadb.atlassian.net/browse/MDEV-4912 i will make this one as blocked by mdev-4912, this will remove problems about 'complicate' the server code, the problem will be changed to 'plugin code' 2013/8/17 Patryk Pomykalski (JIRA) <jira@mariadb.atlassian.net> – Roberto Spadim SPAEmpresarial
            rspadim roberto spadim added a comment -

            hi patryk,

            check that the idea of MDEV-4912, will solve the problem of two others
            MDEV...
            i think we could implement the plugin first, and all others considerations
            about field types could be solved via this interface, only the "native
            field types" should be implmented at "server-side" code (not the "plugin"
            code)

            https://mariadb.atlassian.net/browse/MDEV-4631 - Encrypted column data type
            https://mariadb.atlassian.net/browse/MDEV-274 - The data type for IPv6/IPv4
            addresses in MariaDB

            and the enum could be used as theses mdevs too
            https://mariadb.atlassian.net/browse/MDEV-4913 - External ENUM Field
            definition

            what you think?
            i was talking about this at maria-developer mail list with Sergei Golubchik
            (the plugin, not the external enum field type)

            rspadim roberto spadim added a comment - hi patryk, check that the idea of MDEV-4912 , will solve the problem of two others MDEV... i think we could implement the plugin first, and all others considerations about field types could be solved via this interface, only the "native field types" should be implmented at "server-side" code (not the "plugin" code) https://mariadb.atlassian.net/browse/MDEV-4631 - Encrypted column data type https://mariadb.atlassian.net/browse/MDEV-274 - The data type for IPv6/IPv4 addresses in MariaDB and the enum could be used as theses mdevs too https://mariadb.atlassian.net/browse/MDEV-4913 - External ENUM Field definition what you think? i was talking about this at maria-developer mail list with Sergei Golubchik (the plugin, not the external enum field type)
            rspadim roberto spadim added a comment -

            please add this to 10.1.0 version

            rspadim roberto spadim added a comment - please add this to 10.1.0 version

            People

              Unassigned Unassigned
              rspadim roberto spadim
              Votes:
              2 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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