[Mapbender-dev] Cleaning up the SQL database

[Christoph Baudson (WhereGroup)]

Arnulf Christl schrieb:
> Another background is maintainability of the SQL. Currently keeping the 
> dump up to date is painful and error prone. My hope is that if we split 
> the large SQL chunk up into little pieces it will help maintenance 
> because then the developer of the corresponding module also maintains 
> the SQL snippet. The snippets are stored using the SVN which will also 
> enhance updating for professional users and will allow us to have 
> regular auto-builds over night so that the dev server is always up to date.
> This needs a lot more thought as it will even tie back into packaging, 
> install scripts, etc. Potentially this is better done in the Wiki once 
> we know what we are talking about. Feel free to start this as a new page 
> or tie it to a Trac ticket.

Recently I have looked into the Sahana project (see 
http://www.sahana.lk). The project utilises a seperate folder for 
modules, and each module is again in a sub-folder. The SQL files for 
installing the module are in another subfolder. I believe this is 
similar to what Arnulf suggested.

Here is an excerpt from the Sahana mailing list:

 > In order to move forward on better module installation automation
 > (install, update, versioning, etc), all module writers need to agree on
 > a convention.
 >
 > Here are something we should agree on to allow automation:
 >
 > 1) All database creation scripts go in <mod>/ins/dbcreate.mysql. I know
 > we wanted an abstraction in XML for this, but IMO lets take small steps
 > first. I think most of us are doing this already so it is easy to do.
 >
 > 2) If you require additional setup logic for the module you can put it
 > in <mod>/ins/setup.inc. We only need this if you installation needs
 > additional logic to database creation. There should be a function to
 > install and uninstall the module. Possibly
 >
 >    - shn_mpr_install()
 >    - shn_mpr_upgrate() - upgrade module to new version, keeping data
 >    - shn_mpr_uninstall()
 >
 > 3) A module will be packaged as a .tar.gz for download and installation
 > for efficient download.
 >
 > 4) A module will identify it's version number. We can put this either in
 >   <mod>/conf.inc or in <mod>/ins/setup.inc
 >
 >    $package['mod_mpr_version'] = '0.4';
 >
 > 5) A module will identify dependent and conflicting modules. Again we
 > can put this either in  <mod>/conf.inc or in <mod>/ins/setup.inc
 >
 >    $package['mod_vm_depends'] = array( 'mpr/0.2', 'or', 'gis/0.3-0.4' );
 >    $package['mod_vm_conflicts'] = array ( 'vol', 'dvr/0.3-0.5');
 >
 > BTW I prefer not to include this in conf.inc as we need to keep it light
 > (all mod conf.inc files are loaded on each request).
 >
 > Can we agree between module writers on 1,2,3) to start with so Dinishika
 > can move forward ASAP and we can then discuss how to best implement 4,5)
 > for the next steps?
 >