Thanks guys for the sample data files. I have now verified the upgrade to version 1.9.0 works from 1.7.1, 1.7.2 and 1.8.0 with records containing laps.
There's a couple of significant changes I have just committed related to the data upgrade functionality: 1. I have deleted the "check" start up option and removed the checkDBIntegrity function (r903). This is redundant now that we have a proper data upgrade mechanism. 2. Upgrading from version 1.7.0 or earlier will fail cleanly (r904). Previously the behaviour was likely to leave the DB in a corrupt state. 3. I have split the "add column" and "populate data" stages of two of the upgrade scripts to minimise the chance of a user ending up with a corrupt database if an upgrade fails (r906). I wanted to use transactions to achieve this but I suspect you cannot rollback executed DDL statements. This last change meant the DB version numbering had to change - version 12 has been renumbered to version 14. Normally when this happens you you would need to change the migrate_version value from 12 to 14 in your DB to avoid an upgrade failure the first time you launch after updating. In this case though the last two upgrade scripts are safe to run twice so you won't need to do anything. With these changes I am happy for 1.9.0 to be released. Shall we organise some smoke testing? - Nathan ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Pytrainer-devel mailing list Pytrainer-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytrainer-devel
