topic Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c in Alfresco Archive

[Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Fri, 21 Dec 2012 17:34:35 GMT

BonsoirJe suis en cours de migration sur Alfresco d'une version 3.4.d vers une 4.2.c et je rencontre un problème.Voici la procédure appliquée erveur Alfresco-3.4.c1. sauvegarde de la base de données postgresql d'alfresco-3.4.d, avec la commande suivante g_dump -i -h ${host} -p {port} -U ${user}

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

cleseach — Thu, 27 Dec 2012 06:48:58 GMT

Bonjour JeanJo,

Je n'ai pas testé ce genre de montée de version, donc pas d'aide précise, mais peut-être quelques idées à creuser.
As-tu vérifié que la contrainte est bien présente dans ta base d'origine ?
As-tu vérifié que la contrainte est bien présente dans ton dump ?
As-tu vérifié que la contrainte est bien présente dans ta nouvelle base ?
As-tu tenté une montée de version vers une 4.0 à partir de ta base 3.4 ?

Bonne journée
Charles Le Seac'h

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Thu, 27 Dec 2012 13:10:07 GMT

Merci Charles, je regarde vis à vis des informations que tu m'as données.

Mais ce que je ne comprends pas c'est pourquoi :

Il me DROP la CONTRAINST

SQL: ALTER TABLE alf_node_assoc
    DROP CONSTRAINT fk_alf_nass_snode‍‍

Et après il me dit qu'il n'a plus la relation et que celle-ci n'existe plus ?????

   Error: ERROR: constraint "fk_alf_nass_snode" of relation "alf_node_assoc" does not exist‍

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

cleseach — Thu, 27 Dec 2012 15:35:23 GMT

Je comprends le message comme signifiant : "il est impossible de supprimer la contrainte par ce qu'elle n'existe pas" (pas et non plus) 😉

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Thu, 27 Dec 2012 16:33:12 GMT

Je vais faire le test mais en allant vers une 4.0.e.

Je vais voir si le comportement est identique.
Donc migration d'une 3.4.d vers une 4.0.e.

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Thu, 27 Dec 2012 17:37:05 GMT

pour répondre à Charles

1. As-tu vérifié que la contrainte est bien présente dans ta base d'origine ?
2. As-tu vérifié que la contrainte est bien présente dans ton dump ?
OUI pour le 1 et le 2 car, voici ce que j'ai comme information dans le dup de ma base postgresql en 3.4.c

–
– Name: fk_alf_nass_snode; Type: INDEX; Schema: public; Owner: alfresco; Tablespace: 
–

CREATE INDEX fk_alf_nass_snode ON alf_node_assoc USING btree (source_node_id);‍‍‍‍‍

Je suppose que ceci représente ma CONTRAINTE qu'il ne trouve pas.
Donc celle-ci est bien là …
Je suppose que cela vérifie le point 1 et 2
Dites-moi si je me trompe …

3. As-tu vérifié que la contrainte est bien présente dans ta nouvelle base ?
Pour l'instant je ne peux pas vérifier car la migration via Alfresco plante en cours de route

4. As-tu tenté une montée de version vers une 4.0 à partir de ta base 3.4 ?
Je suis en cours …

Merci de ton soutien …

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Fri, 28 Dec 2012 10:04:23 GMT

Retour de ma migration cette fois de 3.4.c vers la 4.0.e

Le problème est identique à la migration précédente

Voici le message d'erreur :

 2012-12-28 10:38:41,150  ERROR [domain.schema.SchemaBootstrap] [main] Statement execution failed:
   SQL: ALTER TABLE alf_node_assoc
    DROP CONSTRAINT fk_alf_nass_snode
   Error: ERROR: constraint "fk_alf_nass_snode" of relation "alf_node_assoc" does not exist
   File: /opt/alfresco-4.0.e/tomcat/temp/Alfresco/AlfrescoSchema-PostgreSQLDialect-Update-8599693180746613096.sql
   Line: 17
 2012-12-28 10:38:41,161  ERROR [domain.schema.SchemaBootstrap] [main] Schema auto-update failed‍‍‍‍‍‍‍

Voici le contenu du fichier : AlfrescoSchema-PostgreSQLDialect-Update-8599693180746613096.sql

–
– Title:      Add 'assoc_index' column to 'alf_node_assoc'
– Database:   PostgreSQL
– Since:      V4.0 Schema 5008
– Author:     Derek Hulley
–
– Please contact support@alfresco.com if you need assistance with the upgrade.
–

– Cut the original table to just the data
DROP INDEX source_node_id;                      –(optional)
DROP INDEX alf_node_assoc_source_node_id_key;   –(optional)
DROP INDEX fk_alf_nass_snode;
DROP INDEX fk_alf_nass_tnode;
DROP INDEX fk_alf_nass_tqn;
ALTER TABLE alf_node_assoc
    DROP CONSTRAINT fk_alf_nass_snode;
ALTER TABLE alf_node_assoc
    DROP CONSTRAINT fk_alf_nass_tnode;
ALTER TABLE alf_node_assoc
    DROP CONSTRAINT fk_alf_nass_tqn;
ALTER TABLE alf_node_assoc RENAME TO t_alf_node_assoc;

– So now it's just raw data
– Reconstruct the table (leave the sequence as is)
CREATE TABLE alf_node_assoc
(
    id INT8 NOT NULL,
    version INT8 NOT NULL,
    source_node_id INT8 NOT NULL,
    target_node_id INT8 NOT NULL,
    type_qname_id INT8 NOT NULL,
    assoc_index INT8 NOT NULL,
    PRIMARY KEY (id),
    CONSTRAINT fk_alf_nass_snode FOREIGN KEY (source_node_id) REFERENCES alf_node (id),
    CONSTRAINT fk_alf_nass_tnode FOREIGN KEY (target_node_id) REFERENCES alf_node (id),
    CONSTRAINT fk_alf_nass_tqn FOREIGN KEY (type_qname_id) REFERENCES alf_qname (id)
);
CREATE UNIQUE INDEX source_node_id ON alf_node_assoc (source_node_id, target_node_id, type_qname_id);
CREATE INDEX fk_alf_nass_snode ON alf_node_assoc (source_node_id, type_qname_id, assoc_index);
CREATE INDEX fk_alf_nass_tnode ON alf_node_assoc (target_node_id, type_qname_id);
CREATE INDEX fk_alf_nass_tqn ON alf_node_assoc (type_qname_id);


– Copy the data over
–FOREACH t_alf_node_assoc.id system.upgrade.alf_node_assoc.batchsize
INSERT INTO alf_node_assoc
    (id, version, source_node_id, target_node_id, type_qname_id, assoc_index)
    (
        SELECT
           id, 1, source_node_id, target_node_id, type_qname_id, 1
        FROM
           t_alf_node_assoc
        WHERE
           id >= ${LOWERBOUND} AND id <= ${UPPERBOUND}
    );

– Drop old data
DROP TABLE t_alf_node_assoc;

–
– Record script finish
–
DELETE FROM alf_applied_patch WHERE id = 'patch.db-V4.0-NodeAssoc-Ordering';
INSERT INTO alf_applied_patch
  (id, description, fixes_from_schema, fixes_to_schema, applied_to_schema, target_schema, applied_on_date, applied_to_server, was_executed, succeeded, report)
  VALUES
  (
    'patch.db-V4.0-NodeAssoc-Ordering', 'Manually executed script upgrade V4.0: Add assoc_index column to alf_node_assoc',
    0, 5008, -1, 5009, null, 'UNKNOWN', ${TRUE}, ${TRUE}, 'Script completed'
  );
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Et pour finir voici ce que j'ai trouvé dans ma base de données (après restauration) pour ce qui concerne le alf_node_assoc et le fk_alf_nass_snode :

- alf_node_assoc
         + colonnes (5)
              id
              version
              source_node_id
              target_node_id
              type_qname_id
         - contraintes (2)
              alf_node_assoc_pkey
              alf_node_assoc_source_node_id_key
         - index (0)
         - regles (0)
         - trigger (0)‍‍‍‍‍‍‍‍‍‍‍‍‍

Je trouve bizarre de ne pas trouver en effet les index ???
Ceci ne devrait-il pas être mise en place lors de la migration ?

Que dois-je faire.
Merci de vos retours.

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Fri, 28 Dec 2012 10:17:36 GMT

Je rajoute un complément :

Voici ce que j'ai dans mon fichier sql de dump et de restore :

–
– Name: fk_alf_nass_snode; Type: INDEX; Schema: public; Owner: alfresco; Tablespace: 
–
CREATE INDEX fk_alf_nass_snode ON alf_node_assoc USING btree (source_node_id);

–
– Name: fk_alf_nass_tnode; Type: INDEX; Schema: public; Owner: alfresco; Tablespace: 
–
CREATE INDEX fk_alf_nass_tnode ON alf_node_assoc USING btree (target_node_id);

–
– Name: fk_alf_nass_tqn; Type: INDEX; Schema: public; Owner: alfresco; Tablespace: 
–
CREATE INDEX fk_alf_nass_tqn ON alf_node_assoc USING btree (type_qname_id);‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Alors pourquoi je ne les retrouve pas. Ma base à-t-elle déjà été modifiée par les scripts de migration ?

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Thu, 03 Jan 2013 09:34:08 GMT

Je profite de souhaiter la bonne année à tous pour 2013, pour relancer mon problème de migration.

Merci de vos retour.

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Thu, 03 Jan 2013 10:28:34 GMT

Bonjour

Je continue dans ma compréhension du problème de migration.
Donc si je regarde la structure de ma base de données postgresql avant la migration, je trouve bien mes 3 index:

- alf_node_assoc
         + colonnes (5)
              id
              version
              source_node_id
              target_node_id
              type_qname_id
         - contraintes (2)
              alf_node_assoc_pkey
              alf_node_assoc_source_node_id_key
         - index (3)
              fk_alf_nass_snode
              fk_alf_nass_tnode
              fk_alf_nass_tqn
         - regles (0)
         - trigger (0)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Donc mes index sont bien supprimés lors des patchs de migration …

Ce qui confirmerais la remarque de Charles :
"Je comprends le message comme signifiant : "il est impossible de supprimer la contrainte par ce qu'elle n'existe pas" (pas et non plus)"

Alors pourquoi un patch supprime ces index et se plaint ensuite de leurs absences ???

Quelqu'un aurait-il une idée de ce que je dois faire ?

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Thu, 03 Jan 2013 10:39:00 GMT

Je viens de constater quelque chose d'étonnant.
Pourquoi dans le fichier sql d'update dont j'ai parlé dans mon premier POST au début, nous avons cela :

   SQL: ALTER TABLE alf_node_assoc
    DROP CONSTRAINT fk_alf_nass_snode
   Error: ERROR: constraint "fk_alf_nass_snode" of relation "alf_node_assoc" does not exist
   File: /opt/alfresco-4.2.c/tomcat/temp/Alfresco/AlfrescoSchema-PostgreSQLDialect-Update-6627920723547144696.sql
   Line: 17
‍‍‍‍‍‍

le fichier sql, cherche donc à supprimer une CONTRAINTE fk_alf_nass_snode.
Or ceci n'est pas une contrainte mais un INDEX.

Il y aurait pas comme une erreur ????

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Fri, 04 Jan 2013 09:05:16 GMT

Personne n'a aujourd'hui fait de migration d'une 3.4.d vers une 4.x ????

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Mon, 07 Jan 2013 17:06:32 GMT

Une petite relance :wink:

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Thu, 10 Jan 2013 07:46:30 GMT

Bonjour

Mon problème est résolu.

Je prendrais le temps de faire soit une réponse sur ce forum soit un article sur le site de tekonorma.

en attendant, ce que je peux dire, c'est que les scripts d'upgrade mises à disposition dans Alfresco possèdent quelques problèmes de contrôle.

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

digitech — Mon, 04 Feb 2013 14:02:24 GMT

Bonjour,
Je suis un utilisateur Ged Afresco et non un développeur ni spécialiste JAVA.
La plateforme est Centos 6.3 Mysql 5.1.66 Index Lucene dans une machine virtuelle Vmware.
De 3.4.d vers une 4.2.c c'est possible je l'ai fait.( version community standard out of the box)
110 Go. de Datas.

Installer une 4.2C sur une nouvelle machine.
Migrer le Dump .sql
Migrer Le alf_data
La migration echoue sur les tables ACT_ , il faut les supprimer et les recréer grâce
au fichier addingact_tables.sql
https://issues.alfresco.com/jira/secure/attachment/37652/addingACT_tables.sql
La migration se déroule normalement SAUF……….!

Sauf si vous avez défini des règles sur des espaces, la migration échoue:
J'en suis là pour la migration d'un client pour lequel des règles existent sur des espaces:

L'anomalie est répertoriée:
https://issues.alfresco.com/jira/browse/ALF-17483
message: java.lang.ClassCastException: java.util.ArrayList cannot be cast to org.alfresco.service.cmr.repository.ContentData.

Il semble que la solution disponible soit la suppression des règles avant migration ?
Comment les supprimer ?
Faut il supprimer les documents ayants une règle appliquée ??

Merci de votre aide aide et de vos conseils.

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

throwback — Mon, 04 Feb 2013 15:30:35 GMT

Bonjour,

J’ai un problème similaire avec la migration alfresco de 4.0n d vers 4.2.c . Pourriez vous me donner le liens vers la réponse que vous avez trouvée sur Tekonorma ?

Cordialement,

Ian Bagnall

Re: [Résolu] migration alfresco de 3.4.d vers une 4.2.c

jeanjot — Thu, 07 Feb 2013 17:44:00 GMT

L'autre possibilité, est de passé de la version 3.4.d à la version 3.4.e.
C'est à partir de la version 3.4.e qu'activiti à fait son apparition.

Sinon en effet, certaines règles posent problèmes lors de la migration.

De plus en fonction de certaine intégration, comme une connection à OPENLDAP, ne pas oublier de la déclarer.

Pas mal de bidouilles à régler au fur et à mesure.