Keeping python code and database in sync
Frank Millman
frank at chagford.com
Fri Aug 29 09:31:34 EDT 2014
"Chris Angelico" <rosuav at gmail.com> wrote in message
news:CAPTjJmrJBciRuterUKWP=QTQXd8xYquM4nx+oFd-TWM5ooskbA at mail.gmail.com...
> On Fri, Aug 29, 2014 at 10:42 PM, Frank Millman <frank at 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
More information about the Python-list
mailing list