Keeping python code and database in sync

[Frank Millman]

"Chris Angelico" <rosuav at gmail.com> wrote in message 
news:CAPTjJmp68Kh5zCXq50pi0yeaaapnQotxYBg1+f58Mv__Xd99Lg at mail.gmail.com...
> On Fri, Aug 29, 2014 at 11:31 PM, Frank Millman <frank at chagford.com> 
> wrote:
>> 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.
>
> The system I described is intended for cases where each edit builds on
> the previous ones - for instance, if patch 4 creates a table and patch
> 7 adds a column to it, you have to have done them in that order. But
> for that XML data, it sounds as if each update completely overwrites
> all previous ones - is this right? In that case, I'd simplify it:
> after doing all the other patches (anything more complicated than
> "update this one column" can still go through a patching scheme like I
> described), you just hard code an overwrite that sets the appropriate
> field to the current XML. You don't need to update it through all the
> previous states just to get to this one.
>
> Basically, take the simplest approach that will do what you want :)
>

I *think* I understand, but let me restate it in my terms just to be sure.

When I have got this menu definition tool working, I will commit. The files 
involved will probably be one or more 'py' files, and one 'xml' file.

Once downloaded, the 'py' files are automatically 'live', because that is 
how python works. But the xml file will just be sitting in a directory. 
*Something* has to trigger running a program that reads the xml file and 
inserts it into the database.

My idea is to put the 'version number check' in the main program 'start.py'. 
If it detects that an upgrade is required, it will display a warning message 
to the user and then run the upgrade program. The same upgrade program can 
handle both 'schema' changes and (for want of a word) 'meta-data' changes 
such as the menu definition.

Frank