maria-developers team mailing list archive
Mailing list archive
MariaRocks port: why handler::init_with_fields() call is needed + call for comments
I think me and Serg have tried having this discussion before on several
occasions but were not successful due to me not having the details back then.
Now I'm trying with the details.
== Description of the issue ==
Look at MariaDB, the code in TABLE_SHARE::init_from_binary_frm_image (or
open_binary_frm() in mysql-5.6 codebase)
The code goes like this:
/* Allocate handler */
if (!(handler_file= get_new_handler(share, thd->mem_root,
/* Fix key->name and key_part->field */
longlong ha_option= handler_file->ha_table_flags();
for (uint key=0 ; key < keys ; key++,keyinfo++)
for (i=0; i < key_parts; key_part++, i++)
field= key_part->field= share->field[key_part->fieldnr-1];
- a handler object is created at (LOCATION-1). A TABLE_SHARE object exists
at that point, but it has table_share->key_info==NULL. This means the storage
object has no information about the indexes in the table it is representing.
- At (LOCATION-2), the code retrieves ha_table_flags(). A bit below that point
it checks for "ha_option & HA_PRIMARY_KEY_IN_READ_INDEX" (there are also other
checks, both harmful and harmless, but let's focus on this one for now).
In MyRocks, whether HA_PRIMARY_KEY_IN_READ_INDEX flag is set depends on the
datatypes of the primary key columns. However, ha_rocksdb object is requested
to provide ha_table_flags() before it has a chance of looking at the table
DDL and actually knowing the value.
== Solution in MyRocks ==
Basically, there is a new handler::init_with_fields() call which SQL layer
calls after information about table fields is filled.
== Questions ==
Any objections to this approach?
Alternative solutions that do not require a lot of re-writing?
Sergei Petrunia, Software Developer
MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog