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?
On Wed, Mar 30, 2011 at 10:14 AM, Dmitry Lenev <Dmitry.Lenev@stripped> wrote:
> Hello Zardosht!
> * Zardosht Kasheff <zardosht@stripped> [11/03/30 17:56]:
>> Actually, let me put this question another way. Suppose during a call
>> to handler::open, we return an error because the frm file generated
>> from the TABLE* parameter does not match the frm file we stored on
>> disk (due to some system crash at an inopportune time).
>> What, as a storage engine, can we do to get the user back to a well
>> known state where the frm file he is using matches what we have on
> Here is what, AFAIK, NDB does.
> If during call to handler::ha_open() it is discovered that local version
> of table/.FRM is out-of-date HA_ERR_TABLE_DEF_CHANGED error is returned.
> Upon getting such error code in server layer acquires appropriate locks,
> invalidates corresponding entry in table definition cache and then
> calls ha_create_table_from_engine() routine. The latter essentially calls
> discover method of handlerton to get new version of .FRM and writes it
> to disk.
> Hope this helps!
> Dmitry Lenev, Software Developer
> Oracle Development SPB/MySQL, www.mysql.com
> Are you MySQL certified? http://www.mysql.com/certification