Thanks again for the feedback.
My plan is not to silently overwrite things. When handler::open gets
called, if I notice that the frm file generated from the TABLE*
parameter is different than the frm file I have stored on disk, I will
return an error. What I wanted to confirm is that if by some
mechanism, I replace the contents of the bad frm file with what I have
saved (perhaps by some table discovery method?), then the next time
the table is opened, everything should work right.
On Wed, Mar 30, 2011 at 3:21 AM, Stewart Smith <stewart@stripped> wrote:
> On Tue, 29 Mar 2011 21:36:22 -0400, Zardosht Kasheff <zardosht@stripped>
>> I want to make sure that my understanding is correct. Looking at NDB,
>> it seems that they use the functions readfrm() and packfrm() to save
>> the frm file. readfrm() seems get the contents uncompressed, and
>> packfrm() compresses them.
> correct. in NDB we stored the FRM in a compressed format as we keep them
> all in the (in memory) NDB data dictionary.
> There's no requirement to compress them, it just saved valuable memory
> for us (I previously worked on NDB).
>> Suppose I want to just save the raw uncompressed bytes that make up
>> the file. I think I can just use the function readfrm() to get the
>> data. And, if some crash caused the frm file and my saved version to
>> get out of sync, I can just generate a new frm file by saving the data
>> that readfrm() retrieved into a new frm file.
> yes.... but what you really want to do is pass an error back to the
> server like NDB does, if you just silently overwrite things and keep
> going, there is likely to be (as Sergei says) very odd behaviour from
> the upper MySQL layers.
> MySQL keeps a cache of the table definition in data structures so that
> it doesn't have to parse the FRM very often (as that is relatively
> Stewart Smith