From: Zardosht Kasheff Date: March 29 2011 11:59am Subject: Re: storage engine access to serialized version of a TABLE or TABLE_SHARE? List-Archive: http://lists.mysql.com/internals/38271 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Last email did not properly go to internals On Tue, Mar 29, 2011 at 7:58 AM, Zardosht Kasheff wrot= e: > Hello Dmitry and Sergei, > > I will look to see how NDB grabs the frm file. The reason I want it is > that i do not want to risk the frm file and table going out of sync. > It is not a problem now, but I am trying to be proactive. > > Basically, this is what is going on. In our latest release, we have > ported over the new alter table API > (handler::check_if_supported_alter, handler::alter_table_phase1...) > from the MySQL cluster code branch to MySQL server 5.1, and now use > the function handler::alter_table_phase2 to perform a bunch of types > of alter table. This is not crash safe. I know that DDL statements are > not transactional, but I would like to do something better. > Internally, our storage engine is fully transactional. So, what I want > to do is save the new frm file for the altered table in some metadata > dictionary with the same transaction that performs data operations for > the alter (e.g. adds a column to every row of the table). This way, if > there is a crash, our engine can produce what the frm file should be > and the user can recover to a well known state. Right now, we just > cross our fingers and hope the frm file is in sync with the data in > the tables. > > Thanks > -Zardosht > > On Tue, Mar 29, 2011 at 7:46 AM, Dmitry Lenev w= rote: >> Hello, Zardosht, Sergei! >> >> * Sergei Golubchik [11/03/29 10:57]: >>> Hi, Zardosht! >>> >>> On Mar 28, Zardosht Kasheff wrote: >>> > Hello all, >>> > >>> > Is there a way for the storage engine to get some sort of byte stream >>> > that represents a serialized version of a TABLE or TABLE_SHARE object= ? >>> > The goal is to save it locally during handler::create and then check >>> > its contents (as a sanity check) with the TABLE_SHARE passed in durin= g >>> > handler::open. >>> > >>> > Is this possible? And if it is, is there a way to take this serialize= d >>> > data and print what the table looks like in user readable form? >>> >>> I'm afraid not. >>> >>> You can take the generated create table statement, like Stewart >>> suggested, or grab the complete frm file, like NDB does. But I think it >>> may be possible to construct an ALTER TABLE statement that modifies the >>> table definition (frm) only, and your sanity check will fail on the nex= t >>> open. >> >> I think the latter approach should work (after all it works for NDB). >> >> In cases when ALTER TABLE statement modifies only table definition (i.e. >> only .FRM), we still call handler::ha_create_handler_files() method afte= r >> new version of .FRM is installed, in order to inform storage engine abou= t >> the fact that .FRM has been changed. >> >> -- >> Dmitry Lenev, Software Developer >> Oracle Development SPB/MySQL, www.mysql.com >> >> Are you MySQL certified? =A0http://www.mysql.com/certification >> >