Discussion :

[fafa63]

Bonjour,

Je viens d'installer un serveur Postgrès 9.6 avec sa cartouche spatiale Postgis 2.3
Je souhaite maintenant faire migrer mes données depuis mon précédent serveur vers mon nouveau serveur donc :
Postgrès 9.3 / Postgis 2.1 => Postgrès 9.6 / Postgis 2.3
Pour la plupart de mes bases de données et de mes schémas cette opération se passe bien, mais pour certains ça bloque.

Pour certaines de ces bases de données le problème semble venir de la fonction "public.srid(public.geometry)" qui n'existe pas.

Si je me souviens bien, ces données provenaient déjà d'un précédent serveur (Postgrès 9.1 / Postgis 1.5) pour lequel il m'avait déjà fallu utiliser un script "legacy.sql" permettant l'ajout de fonctions dans le 2nd serveur pour permettre l'import des données.
Je peux essayer de faire fonctionner ce script mais il semble me demander l'installation de Postgis 2.1 pour fonctionner, et je préfèrerai éviter l'ajout de vielles fonctions dans mon nouveau serveur.
Comme je passe par un fichier sql pour transférer mes données, je pensais que ça résoudrait mes problèmes, mais non. Effectuer de la conversion de type m'est évoqué dans le message d'erreur mais mes fichiers SQL font plusieurs Go... donc pas simple à ouvrir pour essayer d'appliquer cette solution.

Auriez-vous une solution à me proposer ?

Merci d'avance à vous.

[Arkhena]

Bonjour,

Tout d'abord, votre chemin d'upgrade me paraît un peu trop "simple" pour qu'il se passe correctement...

Voici celui que j'utiliserait:
Postgres 9.3 / Postgis 2.1 => Postgres 9.6 / Postgis 2.1 => Postgres 9.6 / Postgis 2.3
Pour passer de Postgres 9.3 à Postgres 9.6, je vous conseille pg_upgrade.
Pour la migration de PostGis 2.1 à 2.3, je vous laisse lire la documentation (http://postgis.net/docs/manual-2.3/p...ade_extensions)

Cordialement,

Arkhena

[fafa63]

Bonjour et merci pour votre retour,

En effet, sauter autant de version est forcément problématique.
Après analyse de ce qui passe, ou pas, lors de mes transferts de données d'un PC à l'autre, il semble s'avérer que seules quelques tables avec des champs géométriques sont impactées, les même qui avaient déjà nécessitées l'emploi du script "legacy" je pense.
Comme j'ai déjà les 3/4 de mon infrastructure de réinstallée je me demandais aussi si je ne pourrais pas corriger les tables qui posent problème dans mon serveur source avant de ne les exporter : donc "convertir" mes géométries vers les standards postgis 2.1 (et pas me traîner des standards de postgis 1.5 ou quelque chose de se genre) ?

Par contre je ne sais pas trop par quel bout y attraper. Je ne suis pas informaticien de formation, et je ne sais pas non plus si les procédures de migration de PostGis 2.1 à 2.3 peuvent m'aider à résoudre mon problème, je ne les ai jamais utilisées.

Merci

[fafa63]

Re-bonjour,

J'ai poursuivi mes recherches pour modifier nativement mes champs posant problème. Voici une piste trouvée :

Créer un nouveau champ text dans ma table source et y injecter les géométries : (ça marche)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ALTER TABLE cad_test.edi_bati ADD COLUMN wkt_geom text;
update cad_test.edi_bati set wkt_geom = st_astext(the_geom);

Supprimer les champs de géométrie qui posent problème.
Importer la table dans le nouvelle base de données et recréer des champs géométrie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ALTER TABLE cad_test.edi_bati ADD COLUMN geom GEOMETRY;
update cad_test.edi_bati set geom = st_geomfromtext(wkt_geom, 2154);

Cette dernière requête par contre me retourne un message d'erreur que je ne sais pas interpréter :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
ERREUR:  parse error - invalid geometry
HINT:  "01010000206A" <-- parse error at position 12 within geometry
 
********** Erreur **********
 
ERREUR: parse error - invalid geometry
État SQL :XX000
Astuce : "01010000206A" <-- parse error at position 12 within geometry

Quelqu'un saurait-il m'aiguiller ?

Merci

[fafa63]

Bon, finalement je suis parvenu à mes fins.

Je pense savoir pourquoi j'avais cette erreur "interne" à postgres (c'est ce qui semblait ressortir de ce terme "parse error").

En faisant mes tests dans une base "test" sur une table que j'y importais... base dans laquelle je n'avais pas importé, et ne souhaitait pas importer, d'anciennes fonctions postgis qui me posent problèmes... et bien cela plantait.
En faisant toutes mes opérations de recréation de champs directement sur ma table source tout c'est bien passé... et au final l'export de cette même table vers mon nouveau serveur postgres fonctionne aussi !!! C'était donc probablement les fonctions postgis manquantes sur le deuxième serveur qui posaient à nouveau problème.

Faut savoir être patient et pugnace avec ces petites bébêtes !!!

J'espère que cela pourra rendre service à d'autre.