List:Maria Storage Engine« Previous MessageNext Message »
From:Oleksandr \"Sanja\" Byelkin Date:May 29 2008 2:35pm
Subject:Plan of making engine parameters for frm (WL#2938)
View as plain text  
Hi!

The goals of the system as I can see:

- Fast reading frm (time taken by plugin processing of the data should be 
counted too).

- Should be easy usable for plugins with simple requirements and allow plugins 
process some special types if they wants.

Syntax parsing give as pair (key,value) where value will be string. Many 
parameters will need numbers (for numbers, enums or sets) and converting 
string->number every time we need the value IMHO is wasting of CPU time. So 
in frm it is better to store number.

Syntax check and fitting parameters value in allowed range will be done by 
plugin in any case, so IMHO better then write this function for every plugin 
make standard my_opt like function for this which can be usable by most 
plugins.

To allow plugins implement some rare and complex constructions a plugin 
can provide function for parsing and checking unrecognised pairs (if function 
is absent then such pair is error).

According to above I propose following construction:

enum enum_plugin_parameter_type {
  HA_PLUGIN_PARAMETER_STRING,
  HA_PLUGIN_PARAMETER_NUM,
  HA_PLUGIN_PARAMETER_ENUM,
  HA_PLUGIN_PARAMETER_SET
};

struct st_plugin_parameter {
  struct st_plugin_parameter *next;
  LEX_STRING key;
  LEX_STRING value;
  enum enum_plugin_parameter_type type;
}

The list do not contain field/key/table reference because it will be attached 
to field/key/list definition.

After parsing they all will have string values then will be called function 
with this list, array of description of parameters provided by plugin and 
plugin callback.

The function convert type of parameter (if it is needed) and check parameter 
value (can be switchable). For numbers and enums after parsing type will be 
changed and value will contain binary data.

In the frm data will be stored according to its type (to avoid string -> 
number conversion after frm read). reading frm parameters will generate the 
same list (on which plugin can apply check function in debugging purposes or 
to process very specific for this plugin complex constructions which was 
saved in strings.

In the frm we will store length of whole block of parameters and its number 
(4/2 bytes). For for every option we will store:

1 byte: Belong to table/field/value
2 bytes: (if needed): key/field number
1 byte: Type (string/num/enum/set) (can be combined with first byte)
1 byte: key length
2 bytes: data length
<key value>
<data>

The only problem I see is how to pass some unified information about 
table/field/key to handler callback for processing unrecognized by simple 
parser parameters (need for advanced parameters check). Because Parser and 
frm reader collect information about table/field/key in different structures 
(actually for parser it is C++ object which add problems for interface)

Simple parameter parser will work with array of descriptors (like my_opts) 
where name/type/max/min values will be listed. Plugin provide 3 arrays: 
table/field/key.
Thread
Plan of making engine parameters for frm (WL#2938)Oleksandr \"Sanja\" Byelkin29 May
  • Re: Plan of making engine parameters for frm (WL#2938)Oleksandr \"Sanja\" Byelkin2 Jun