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? > _______________________________________________ Mapbender_dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev
