Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #77274 > unrolled thread

Re: Keeping python code and database in sync

Started by"Frank Millman" <frank@chagford.com>
First post2014-08-29 15:31 +0200
Last post2014-08-29 15:31 +0200
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Keeping python code and database in sync "Frank Millman" <frank@chagford.com> - 2014-08-29 15:31 +0200

#77274 — Re: Keeping python code and database in sync

From"Frank Millman" <frank@chagford.com>
Date2014-08-29 15:31 +0200
SubjectRe: Keeping python code and database in sync
Message-ID<mailman.13608.1409319097.18130.python-list@python.org>
"Chris Angelico" <rosuav@gmail.com> wrote in message 
news:CAPTjJmrJBciRuterUKWP=QTQXd8xYquM4nx+oFd-TWM5ooskbA@mail.gmail.com...
> On Fri, Aug 29, 2014 at 10:42 PM, Frank Millman <frank@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


[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web