Re: About definition of I_S tables

[Sergei Golubchik]

Hi, scut_tang!

On Jun 03, scut_tang wrote:
> Have a good vacation, Sergei.

Thanks.

> >P_S has numerous problems because of physical frm files. There are
> >quite a few bugs there, for example related to users doing
> >CREATE/ALTER/DROP on P_S tables.
> >
> >frm tables have to be pre-created in mysql_install_db (that's the
> >script that creates all system tables, like mysql.user, and so on).
> >
> >This design doesn't really work for plugins. Any plugin may install
> >I_S table any time, so we cannot pre-create them all. And a user can
> >unload a plugin any time - the table have to dissapear automatically.
> >And a user can load a new version of the plugin with a different
> >structure of the same I_S table - the table must be automatically
> >created in the new format. Supporting all this with physical frm
> >files would be really painful.
> >
> >So, I'd rather have I_S tables completely virtual, like they are now.
> >No physical frm files.
> >
> I got what you said. I have a new idea.
> The traditional implementation, which has .frm file, is:
> dispatch_command -> mysql_parse -> mysql_execute_command ->
> execute_sqlcom_select -> open_and_lock_tables ->
> open_and_lock_tables_derived -> open_tables ->open_table ->
> open_table_from_share -> ha_open -> open(storage engine).  The TABLE
> *table and TABLE_SHARE *table_share structures are filled in
> open_table and open_table_from_share from informations provided .frm
> file.
>  
> And my new idea is:
> Omits the functions open_table and open_table_from_share, after
> reaches I_S storage engine, ha_infoschema::open fills the TABLE *table
> and TABLE_SHARE *table_share structures by our own definitions of I_S
> tables.  After that, others functions of I_S storage engine, like
> rnd_next, index_read etc, can use TABLE *table and TABLE_SHARE
> *table_share structures.
>  
> If user does not install the I_S storage engine plugin, in funciton
> open_tables return message like "INFORMATION SCHEMA Storage engine
> does not install.".
>  
> Does it work?

Yes, but I think it would be easier to go just a bit deeper. That is to
keep open_table() and open_table_from_share() as is, and implement the
function to create a TABLE_SHARE without an frm file. When TABLE_SHARE
exists, open_table_from_share() will work normally, no need to modify
it.

And the simplest way to create a custom TABLE_SHARE, I suppose, is a
table discovery - ha_create_table_from_engine() -> ha_discover().

But current discovery uses binary frm shipping, that is, if we'd use it,
we'd need to generate a proper binary .frm file out of ST_FIELD_INFO
array. It would be easier to generate TABLE_SHARE directly, I suppose.

To do that we need to modify ha_create_table_from_engine() slightly.
Currently it expects ha_discover to allocate a buffer and put frm image
there. We can change it to expect a properly filled TABLE_SHARE out of
it. And the rest of the ha_create_table_from_engine() (that writes frm,
reads it back - basically almost everything in the current
ha_create_table_from_engine()) can be moved to a separate helper
function write_frm_image_and_fill_table_share().

Regards / Mit vielen Grüßen,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg@stripped>
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Engineer/Server Architect
/_/  /_/\_, /___/\___\_\___/  Sun Microsystems GmbH, HRB München 161028
       <___/                  Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring