On Wed, 06 Apr 2011 23:23:03 +0200, Jonas Oreland <jonas.oreland@stripped> 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
