Siddharth Prakash Singh schrieb:
Hello devs,
I wanted to suggest some changes regarding where the update sql dumps
should be placed.
I propose to place it in "update/db/" folder. For example update sql
dumps of MySQL utf-8 should be placed in "update/db/mysql/UTF-8" .
Notice it is "UTF-8" and not "utf8". This is exactly the characters
defined for CHARSET in mapbender.conf. This convention will make the
script more flexible. Also, I am suggesting to place the update sql
dumps in "update" folder rather than in "resources" folder. This would
help in making the install script. Resources folder should contain the
sql files for a fresh install.
This is just my opinion.
Please comment.
Siddharth and I discussed this on IRC yesterday.
I think changing the folder names according to the setting in
mapbender.conf is a sensible thing to do. Example
resources/db/pgsql/UTF-8/
resources/db/mysql/ISO-8859-1/
instead of
resources/db/postgresql/utf8/
resources/db/mysql/iso/
We agreed upon discarding the idea of a separate update folder.
Siddharth argued that it would make sense to keep the update scripts
modular (in a way, this is a good thing), but in the end we agreed upon
storing the update SQLs in the resources folder, in order to separate
code and data.
On Wed, Aug 13, 2008 at 3:13 PM, Christoph Baudson
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Up to now all files were handled manually, which was quite painful.
Here are some ideas for an automated build of the database dumps.
(1) The folder "resources/db/update" will be deleted from SVN. The
update scripts will be stored seperately for MySQL and PostgreSQL
in "resources/db/mysql/utf8/update/" and
"resources/db/postgresql/utf8/update/" (Read about iso-8859-1
later on).
(2) These update folders will contain subfolders for each version
(we have to come up with a naming convention, like
"<timestamp>_<version_from>_to_<version_to>"). The <version_from>
and <version_to> names should also include release candidates.
We also discussed the naming convention: The proposal above allows you
to order the folders chronologically, and is also human readable. I
guess we agreed the convention makes sense.
(3) These subfolder will include various types of update SQLs
(3a) schema updates
(3b) default application updates (changes in "gui", "gui1"...)
(3c) custom application updates
(4) By this, we store a history of update SQLs. The automated
update routine by Siddharth can then easily find and execute the
necessary update SQLs.
(5) The file "resources/db/mysql/utf8/mysql_data.sql" will be
removed. It will be generated using a PHP script that reads and
modifies the file "resources/db/postgresql/utf8/pgsql_data.sql".
(6) The folders "resources/db/mysql/iso" and
"resources/db/postgresql/iso" will be removed from SVN.
(7) The iso-8859-1 data SQLs and update SQLs will be generated by
a PHP script, which converts the character set via iconv (using
transliteration). This script has already been written and is
already being used for building Mapbender 2.5. Of course, some
data, like translations to the bulgarian language cannot be
converted; missing characters will be displayed as question marks.
(8) The files "resources/db/mysql/mysql_schema.sql" and
"resources/db/postgresql/pgsql_schema.sql" (and
"pgsql_set_sequences.sql") will be generated automatically from an
entity-relationship graph; the graph will be generated in Dia, and
the SQL export will be done via the plugin tedia2sql. See
http://www.mapbender.org/Talk:Deployment for details
This means that the files
mysql_schema.sql
pgsql_schema.sql
will be generated dynamically, and should *only* be updated only by an
automated routine. We should create a new file
mysql_gettext.sql
pgsql_gettext.sql
for the i18n funtion. The build script can then merge the gettext
function into the schema SQL generated from the ER-model.
I propose to name the dia file like this
schema_<version number>.dia
and store it in the folder
resources/db/
(9) The only thing that will have to be done manually are the
update SQLs and the PostgreSQL data dump. The data dump could
later be generated automatically as well. We should somehow create
an API for Mapbender, so that some kind of script automatically
builds the template application like "gui", "gui1" and also loads
WMS, WFS etc. But this is beyond 2.6 imho.
Please share your own ideas. We should discuss all these ideas and
make a motion out of it, so that this mechanism will be used from
2.6 onwards.
--
_______________________________________
W h e r e G r o u p GmbH & Co. KG
Siemensstraße 8
53121 Bonn
Germany
Christoph Baudson
Anwendungsentwickler
Fon: +49 (0)228 / 90 90 38 - 15
Fax: +49 (0)228 / 90 90 38 - 11
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
www.wheregroup.com <http://www.wheregroup.com>
Amtsgericht Bonn, HRA 6788
_______________________________________
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
_______________________________________
_______________________________________________
Mapbender_dev mailing list
[email protected] <mailto:[email protected]>
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
--
Siddharth Prakash Singh
http://www.spsneo.com
------------------------------------------------------------------------
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
--
_______________________________________
W h e r e G r o u p GmbH & Co. KG
Siemensstraße 8
53121 Bonn
Germany
Christoph Baudson
Anwendungsentwickler
Fon: +49 (0)228 / 90 90 38 - 15
Fax: +49 (0)228 / 90 90 38 - 11
[EMAIL PROTECTED]
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
_______________________________________
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
