Migration v5 - Migraiton SQL POSTGRE

Tags: #<Tag:0x00007fdd46e9a540>

Bonjour,

Nous avons opéré une migration en v5 ce matin. Ça ne s’est pas super bien passé mais on a un environnement qui marche a priori correctement

Le problème vient du script de migration de la BDD de p24 en v5 p00, logs ci-joints.
Les logs qui vous intéresseront le plus sont dans le fichier ligne 91 à 126 concernant la migration en P00.
Il y a des erreurs de types “already” exists dans la mesure ou il y a eu un premier deploiement en echec.

J’ai identifié 3 instructions qui posent problème:
ALTER TABLE m_object ALTER COLUMN TYPE varchar2(10), ligne 116
ALTER TABLE web_news ALTER COLUMN web_lang varchar(3) NOT NULL, ligne 120
ALTER TABLE m_field ADD COLUMN fld_speech varchar2(10), ligne 123

J’ai pu compenser les erreurs concernant les varchar en passant les requetes à la mains en utilisant un varchar(10) au lieu du varchar2.

Suite a cette migration nous avons donc un environnement de dev qui à l’air opérationnel, on a pas encore assez de recul pour voir si on a des erreurs persistantes.

Merci pour votre retour. nous attendrons vos retours pour effectuer d’autres déploiements.
tentative migration BDD.csv (58.4 KB)

Oui clairement ces varchar2 sont des coquilles ça sera corrigé dans le build de ce soir.

Je passe votre post en “Defect” car c’est le cas et que votre post n’a rien de spécifique.

Oui il y a du y avoir un raté avec le patch Oracle… sur PostgreSQL la syntaxe est la suivante :

ALTER TABLE m_object ALTER COLUMN obj_srh_predef TYPE varchar(10);
ALTER TABLE web_news ALTER COLUMN web_lang TYPE varchar(3) NOT NULL;
ALTER TABLE m_field ADD COLUMN fld_speech varchar(10);

La non normalisation des ordres DDL entre les SGBDR nous pose toujours des soucis.

@francois je fais les corrections sur les différentes branches

PS: les erreur liées au rejeu des patches SQL (genre “already exists”) peuvent être ignorées, la mécanique d’upgrade ne peut pas faire le tri entre ce qui a déjà été fait et ce qui doit encore être fait, surtout avec PostgreSQL qui ne gère pas les syntaxes “if (not) exists” pour toutes les versions supportées par Simplicité.

Super, merci pour le retour !

Ceci dit, j’ai bien essayé cette requête :

ALTER TABLE web_news ALTER COLUMN web_lang TYPE varchar(3) NOT NULL;

[Code: 0, SQL State: 42601] ERROR: syntax error at or near “NOT”
Position : 60 [Script position: 60 - 63]

En plus du problème de syntaxe, je ne vois pas de colonne web_lang dans le table web_news.

row_id integer (null)
created_dt timestamp without time zone (null)
created_by character varying 100
updated_dt timestamp without time zone (null)
updated_by character varying 100
nws_date timestamp without time zone (null)
nws_title character varying 100
nws_image integer (null)
nws_description text (null)
nws_expdate timestamp without time zone (null)
nws_display character varying 10
nws_lang character varying 3

Je pense pas que ce soit une table indispensable au bon fonctionnement de notre application mais je prefere que tout soit d’équerre :)

Il faut à priori splitter en 2 lignes et renommer la colonne:

ALTER TABLE web_news ALTER COLUMN nws_lang TYPE varchar(3);
ALTER TABLE web_news ALTER COLUMN nws_lang SET NOT NULL;

Oui, PG c’est vraiment une galère ;-)

L’objectif du patch est de recréer l’index unique de cette table.
Historiquement (en V3) cette colonne nws_lang était optionnelle, mais Oracle refuse de créer un index unique si une colonne de l’index est null.

1 Like