Bonjour,
Je parviens sans souci à faire une installation clean de GéoSource 2.11 dans un Tomcat 6 en utilisant le fichier WAR et en déclarant l'utilisation d'une base MySQL.
J'ai donc un GéoSource 2.11 vierge qui semble parfaitement fonctionner (pas fait de tests poussés).
Je cherche ensuite à faire démarrer le GéoSource sur ma base de données existante qui correspond à un GéoSource 2.9.1.
Démarrage direct -> erreur. Ce qui me semble normal.
J'ai ensuite tenté d'appliquer les scripts présent dans WEB-INF/classes/setup/sql-geosource/migrate/v2110, à savoir :
1-migrate-db-mysql.sql
2-migrate-default.sql
3-create-tmp-tables-mysql.sql
4-copy-to-tmp-default.sql
5-recreate-old-tables-mysql.sql
6-copy-from-tmp-default.sql
Mais impossible d'aller plus loin, dès l'étape 1 j'ai une erreur : "Table 'harvestersettings' already exists". Ce qui semble indiquer que la structure de la base ne doit pas loin d'être correcte.
Alors j'ai tenté d'utiliser le script migrate-db-mysql.sql présent dans le répertoire WEB-INF/classes/setup/sql-geosource/migrate/v290 en me disant : "en fait le nom du répertoire = ma version de départ de GéoSource".
Et là : j'ai une erreur MySQL dès la première requête : ALTER TABLE Users ADD security varchar(128) default '';
MySQL a répondu : #1060 - Duplicate column name 'security'
Ma question est donc : quels scripts SQL / requêtes SQL faut-il appliquer pour migrer une base GéoSource 2.9 vers une 2.11 ?
Merci d'avance pour les réponses.
PS1 :
post en relation avec http://osgeo-org.1560.x6.nabble.com/Geosource-211-Script-creation-table-tp5150433p5150435.html
PS2 :
J'ai tenté d'autres scripts et j'obtiens très très souvent des erreurs engendrées par la suppression de clés étrangères / avec contraintes.
Maël REBOUX
Service SIG mutualisé Ville de Rennes / Rennes Métropole
Chargé de mission "diffusion"
02 99 86 63 71
Re-Bonjour,
J'ai trouvé l'origine de mes problèmes.
Ma base et mes tables GéoSource utilisent le moteur InnoDB.
Or, si l'utilisation de InnoDB garantie surtout l'intégrité des données et une meilleure récupération des données en cas de crash de MySQL, la modification des tables contenant des clés étrangères est une galère.
Pour contourner ce problème, j'ai donc dumpé la base de production, modifier le fichier SQL résultant en modifiant le moteur pour chaque table et remonté une base "geosource_211_myisam".
Sur cette base j'ai appliqué les scripts d'upgrade (qui contiennent des bogues, j'y reviendrai) sans souci.
J'ai ensuite dumpé cette base, modifier les références de moteur dans le fichier SQL et remonté le tout vers une base "geosource_211".
Cela semble fonctionner mais je n'ai pas encore réalisé d'édition ou d'import de fiches, de thesaurus, etc, etc.
A voir donc.
Pour ceux qui veulent des infos sur MyISAM / InnoDB :
http://sql.sh/1548-mysql-innodb-myisam
Maël REBOUX
Service SIG mutualisé Ville de Rennes / Rennes Métropole
Chargé de mission "diffusion"
02 99 86 63 71
Suite des essais de migration d'une base GéoSource 2.9.0/1 vers 2.11.
Ne pas tenir compte de la procédure décrite dans mon précédent message : elle est erronée.
Il n'est pas nécessaire de dumper et réintégrer.
En fait, il suffit de demander la désactivation des clés étrangères avec
SET FOREIGN_KEY_CHECKS=0;
[requêtes...]
SET FOREIGN_KEY_CHECKS=1;
L'autre problème rencontré est les nombreux fichiers à exécuter.
J'ai tout regroupé dans un seul que voici ci-joint.
Il contient en plus des corrections / adaptations propres à MySQL. Exemples : pb déclaration longueur de champ, rajout de champs, etc.
Ces rajouts sont identifiés par "FIX" ou "FIXME".
Une fois ce script de migration appliqué à une base 2.9, il semble que tout fonctionne mais je n'ai pas encore testé l'import, l'édition, etc.
Pour clore la phase de migration j'ai voulu comparer la structure de ma base migrée avec la structure d'une base vierge.
Il y a des dizaines de divergences !
Cela va de la longueur ou du type des champs à leur existence même en passant par la définition des clés primaires et étrangères.
A priori et après une lecture rapide : rien de vital mais sur le coup : on doute.
Ci-joint un fichier de diff unifié pour les expert(e)s.
@fxprunayre
Que faut-il faire ?
Faut-il tenter de patcher la base pour se rapprocher du modèle de données "vierge" 2.11 ?
Cordialement,
Maël REBOUX
Co-animateur du pôle métier INSPIRE de GéoBretagne
Service SIG mutualisé Ville de Rennes / Rennes Métropole
Chargé de mission "diffusion"
02 99 86 63 71
(attachments)
migrate_2.9_2.11_tout.sql (24.8 KB)
gs_2110_diff.txt (32.5 KB)