"Chris Angelico" <ros...@gmail.com> wrote in message news:CAPTjJmrJBciRuterUKWP=qtqxd8xyqum4nx+ofd-twm5oos...@mail.gmail.com... > On Fri, Aug 29, 2014 at 10:42 PM, Frank Millman <fr...@chagford.com> > wrote: >> It is a simple matter to write a program that updates the database >> automatically. The question is, what should trigger such an update? My >> first >> thought is to use a version number - store a version number in the >> working >> directory, and have a matching number in the code. If someone downloads >> the >> latest version, the numbers will no longer match, and I can run the >> upgrade >> program. > > This is a well-known problem, and there's no really perfect solution. > The first thing to consider is: What happens if someone back-levels > the program? If you can afford to say "never back-level past a schema > change", then you can simply version the schema, independently of the > code. A simple incrementing integer will do - you don't need a > multipart version number.
Thanks, Chris, this sounds ideal for my current requirements. You mentioned keeping schema changes to a minimum, which I agree with, but that is not actually my main problem. Right now I am writing a tool to allow users to view and modify menu definitions. The tool is effectively a form definition, which in my system is expressed in xml and stored in the database in the 'sys_form_defns' table. The raw xml will be uploaded as part of the commit, and will be downloaded when someone pulls the latest version, but it still has to be inserted into the database before it is accessible. It is not a problem - I can use the same mechanism that you described - but it will be happening quite a lot until the system settles down. Frank -- https://mail.python.org/mailman/listinfo/python-list