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)
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'
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
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)
what you think?
i was talking about this at maria-developer mail list with Sergei Golubchik
(the plugin, not the external enum field type)
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)
Task
Minor
MDEV-4912 Data type plugin API version 1
Why wouldn't you just use an int/bigint column and a dictionary table by yourself? Why complicate the server code?