[Mapbender-dev] Cleaning up the SQL database
Christoph Baudson (WhereGroup)
christoph.baudson at wheregroup.com
Tue Jun 12 05:07:36 EDT 2007
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?
>
More information about the Mapbender_dev
mailing list