I personally am against this 'version' table concept altogether. It just makes
life difficult for expert users without meaningfully solving the problem it seeks to
solve.
It's just an arbitrary table; what guarantees does it offer that the version of the
definition of table X corresponds to the version identifier in the version table? And the
fact that it's called 'version' and can only be called 'version' and
must reside in the same schema and database as that which corresponds to the db_url of
certain DB-backed modules is an additional source of pain in certain situations.
At the very least, it ought to be possible to turn the whole concept off, globally, with a
modparam or a core directive. Ideally it should be gotten rid of altogether. It
doesn't stop anyone from using wrong versions of table definitions--a noble and
laudable goal. It just adds this annoying dependency that has to be maintained
constantly.
It's possible to validate table definitions by inspecting schematic metadata (in
major RDBMs), but I can understand why interest in implementing something so DBM-specific
in the DB APIs may be limited. Maybe something like inserting a test row and then
selecting * and doing an MD5 sum on it can work too. Or maybe the program can just trust
that everyone's a big kid and can manage their DB tables, as they do with other
applications that also change versions, alter their table definitions over time, etc. :-)
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE, Suite 700
Atlanta, GA 30309
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web:
http://www.evaristesys.com/,
http://www.csrpswitch.com/
Sent from my BlackBerry.