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. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
