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?
On Thu, Apr 7, 2011 at 1:03 AM, Stewart Smith <stewart@stripped> wrote:
> On Wed, 06 Apr 2011 23:23:03 +0200, Jonas Oreland <jonas.oreland@stripped>
>> 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