From: Zardosht Kasheff Date: April 7 2011 4:30pm Subject: Re: storage engine access to serialized version of a TABLE or TABLE_SHARE? List-Archive: http://lists.mysql.com/internals/38291 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Another question. How is this supposed to work with partitioning? In fact, I do not see how NDB does it. In the call to handler::create on a partitioned table, the input parameter name, which NDB passes to readfrm, is not the name of the frm file. It is like the name of a temporary file. The frm file is actually form->s->path.str. At least this is the behavior I see in my engine. Then, when one runs "alter table drop partition", I see no indication in the storage engine layer that the frm file has changed. I see no call to handler::create_handler_files. How would an engine that is being partitioned become aware that the frm file has changed? I was thinking of disabling this behavior I am trying to implement for tables partitioned with our engine. Is there a way to find out if a table is a partition? Would doing a strcmp(name, form->s->path.str) work? Would checking form->part_info to see if it is NULL work? Thanks -Zardosht On Thu, Apr 7, 2011 at 1:03 AM, Stewart Smith wrote: > On Wed, 06 Apr 2011 23:23:03 +0200, Jonas Oreland wrote: >> On 04/06/11 18:32, Zardosht Kasheff wrote: >> > Hello all, >> > >> > Another question on this. Is the ONLY way an frm file may change is if >> > an alter table occurs that is a metadata change only? >> >> if I understand your question correctly you should >> look in handler.cc : update_frm_version >> it makes a pwrite to frm-file, updating version... > > This is actually the MySQL Server version that last ran CHECK or REPAIR > on the table (or that created it, but it's a different code path to > update_frm_version). See also create_frm() in sql/table.cc > > This is different to the FRM file format version - which FRM_VER would > lead you to believe is 6, INFORMATION_SCHEMA.TABLES column VERSION would > lead you to think is 10 (it's NOT anything to do with how many times > you've changed the table, it's the FRM file format version > number-ish). The I_S column is really just the byte length number from > the FRM file which is FRM_VER + 3 + test(create_info->varchar). I'm > still not exactly sure what kind of sense this is meant to make. > > mysql_compare_tables in sql/sql_table.cc does some working out on if > it's just a metadata only change. I'd have a bit of testing around this > as I'm not sure the engines are properly informed... and I do casually > wonder if there may be a NDB bug or two around this. > > Of course, correctly navigating around a lot of this code is roughly > akin to drawing an accurate map of a large bowl of spaghetti. > > -- > Stewart Smith >