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