Rafal Somla, 22.09.2009 07:57:
> Note that I proposed another solution for the problem in BUG#47484
> (mentioned in the bug report). This is to have the logical drivers save
> and restore AUTO_INCREMENT in the table data snapshot they create. Thus
> no need to change image format.
Thanks for the proposal. Please note that I added this clarification to
the bug report:
IMHO it is just by chance, not by design, that the MyISAM driver
preserves that auto_increment value.
The MEMORY driver does _not_ preserve the value. I'm sorry if I was
unclear about it. A restored MEMORY table shows tha auto_increment value
as the highest existing value plus one. This is not necessarily the same
value as of the time of backup. The value can be higher than max+1, not
only by explicit ALTER, but also by deleting the row with the max value.
If we want to handle AUTO_INCREMENT through the drivers, we must
document another requirement for native drivers, and change both,
default and CS drivers. The resulting images may come as a surprise to
old MySQL servers. They might fail on the additional information in the
table data chunks.
I wonder if this change can be understood as not to change the image
format, while using the "extra" metadata information can be understood
as a change in the image format. In contrast, I would expect, "old"
servers to ignore the "extra" metadata information, and read over it,
since it is not used yet.
But I might fail to understand what the initial purpose for the "extra"
information was. Perhaps using it for an auto_increment value would
violate the design. Can you please explain?
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028