[spip-dev] Restauration suicidaire

Dev
1

Hello

En 2.0 quand je restaure un dump de préfixe de table standard ("spip_") vers un site dont le préfixe est autre, pas de souci.

En 2.1, la même opération aboutit à une base réduite à l'utilisateur principale.

Quand je compare les logs, après le message "fin de l'archive, statut: ok", se trouve en suite le message: "28 tables effacees ...." dans le cas de la 2.1.

J'aurais aimé raffiné sur le numéro de Commit, mais la nouvelle présentation dans Trac depuis le passage à Git fait que les numéros de version n'apparaissent pas clairement (le Select-html n'est pas positionné automatiquemnt) c'est ingérable.

En tout cas c'est un bug majeur.

Committo,Ergo:Sum

2

En 2.1, la même opération aboutit à une base réduite à l'utilisateur principale.

je ne comprends pas.

En tout cas c'est un bug majeur.

je ne reproduis pas

1) un spip neuf 2.1.2 [16017]) tout juste installé avec des tables
préfixées 'perso'
   => 33 tables crées : perso_articles, perso_auteurs...

2) un dump compressé effectué à partir d'un spip 2.1.2 SVN [16589]
dont les tables sont préfixées 'spip' (installation par défaut)

3) restore lancé depuis le spip 'perso' (ecrire/?exec=admin_tech)
   => toutes les tables sont bien restorées (les contenus du dump sont
      bien là) et toujours préfixées 'perso'

4) dans les logs :
   Nov 19 15:29:43 127.0.0.1 (pid 2176) Action super-admin: Restauration
       de la sauvegarde Mon_site_SPIP_20101119.xml.gz
   Nov 19 15:29:43 127.0.0.1 (pid 2176) meta: import_all
       import_all,admin_63ebff0888,Mon_site_SPIP_20101119.xml.gz,
       dump.xml,../tmp/dump/
   Nov 19 15:29:43 127.0.0.1 (pid 2176) admin _1_ (init)
   Nov 19 15:29:43 127.0.0.1 (pid 2176) Debut de l'importation (charset:
       utf-8, format: 1.3)
   Nov 19 15:29:43 127.0.0.1 (pid 2176) langues utilisees: fr
   Nov 19 15:29:43 127.0.0.1 (pid 2176) 28 tables effacees
       spip_mots_syndic, spip_mots_rubriques, spip_mots_forum,
       spip_mots_documents, spip_mots_breves, spip_petitions,
       spip_documents_liens, spip_auteurs_articles, spip_mots_articles,
       spip_articles, spip_auteurs, spip_breves, spip_messages,
       spip_mots, spip_groupes_mots, spip_rubriques, spip_documents,
       spip_types_documents, spip_syndic, spip_syndic_articles,
       spip_forum, spip_signatures, spip_auteurs_rubriques,
       spip_auteurs_messages, spip_resultats, spip_versions,
       spip_versions_fragments, spip_urls
   Nov 19 15:29:43 127.0.0.1 (pid 2176) noimport:
   Nov 19 15:29:43 127.0.0.1 (pid 2176) liste:spip_mots_syndic,
       spip_mots_rubriques,spip_mots_forum,spip_mots_documents,
       spip_mots_breves,spip_petitions,spip_documents_liens,
       spip_auteurs_articles,spip_mots_articles,spip_articles,
       spip_auteurs,spip_breves,spip_messages,spip_mots,
       spip_groupes_mots,spip_rubriques,spip_documents,
       spip_types_documents,spip_syndic,spip_syndic_articles,
       spip_forum,spip_signatures,spip_visites,spip_visites_articles,
       spip_referers,spip_referers_articles,spip_auteurs_rubriques,
       spip_auteurs_messages,spip_meta,spip_resultats,spip_versions,
       spip_versions_fragments,spip_urls
   Nov 19 15:29:43 127.0.0.1 (pid 2176) Analyse de spip_articles
       (commence en 211)
   Nov 19 15:29:44 127.0.0.1 (pid 2176) 157 entrees
   ...
   Nov 19 15:29:44 127.0.0.1 (pid 2176) Analyse de spip_urls
       (commence en 1005047)
   Nov 19 15:29:44 127.0.0.1 (pid 2176) 25 entrees
   Nov 19 15:29:44 127.0.0.1 (pid 2176) fin de l'archive, statut: ok
   Nov 19 15:29:44 127.0.0.1 (pid 2176) langues utilisees: fr
   Nov 19 15:29:44 127.0.0.1 (pid 2176) prochain postdate:
   ...

3

en revanche si je veux sauvegarder cette base (depuis le spip aux tables préfixées 'perso'), la page ecrire/?exec=admin_tech me propose une liste de tables cochées par défaut, spip_articles, spip_auteurs, ... et décochées par défaut perso_articles, perso_auteurs, ... avec le même nombre d'enregistrement.

c'est un peu confusionnant, même si ça peut se comprendre : un dump aux tables préfixées spip_ étant 'réinjectable partout', un dump aux tables préfixées perso_ 'créant' de nouvelles tables sur une base aux tables préfixées spip_

4

En fait c'est juste ce formulaire qui est embuggué, car si tu lances la sauvegarde comme ça, il va bien prendre les tables perso_ ...
les spip_xxx étant naturellement traduites en perso_xxx

Cédric

5

Précisions supplémentaires.
Ma sauvegarde commence par:

<SPIP
  version="2.0.11"
  version_base="14558"

Si je remplace 14558 par le numéro courant (15828) ça marche.

Il va donc executer ceci dans maj/svn1000.php :

// refaire les upgrade dont les numeros sont inferieurs a ceux de la branche 2.0
// etre sur qu'ils sont bien unipotents(?)...
$GLOBALS['maj'][14559] = $GLOBALS['maj'][13904]+$GLOBALS['maj'][13929]+$GLOBALS['maj'][14558];

// Restauration correcte des types mime des fichiers Ogg
// http://trac.rezo.net/trac/spip/ticket/1941
// + Types de fichiers : f4a/f4b/f4p/f4v/mpc http://en.wikipedia.org/wiki/Flv#File_formats
$GLOBALS['maj'][15676] = array(array('upgrade_types_documents'));

// Type de fichiers : webm http://en.wikipedia.org/wiki/Flv#File_formats
$GLOBALS['maj'][15827] = array(array('upgrade_types_documents'));

// IP en 40 caracteres pour IP v6
$GLOBALS['maj'][15828] = array(array('sql_alter',"TABLE spip_forum CHANGE `ip` `ip` VARCHAR(40) DEFAULT '' NOT NULL"));

mais je me demande si ce n'est pas lié au fait même d'appeler maj_while.

Committo,Ergo:Sum

6

Ma sauvegarde commence par:

<SPIP
  version="2.0.11"
  version_base="14558"

Si je remplace 14558 par le numéro courant (15828) ça marche.

...

mais je me demande si ce n'est pas lié au fait même d'appeler maj_while.

Je confirme: le fait d'avoir un numéro différent fait planter, indépendamment de l'impact sur la base.
Ce que je cromprends c'est que ce bout de code ci:

    include_spip('base/serial');
    $GLOBALS['tables_principales']=array();
    base_serial($GLOBALS['tables_principales']);
    include_spip('base/auxiliaires');
    $GLOBALS['tables_auxiliaires']=array();
    base_auxiliaires($GLOBALS['tables_auxiliaires']);
    $GLOBALS['tables_jointures']=array();
    include_spip('public/interfaces');
    declarer_interfaces();
    include_spip('base/upgrade');

qui apparait 2 fois est exécuté 2 fois dans ce scénario, ce qui ne me parait pas le but souhaité.
Je ne comprends pas trop l'introduction de tout ça, alors que ce scénario marchait auparavant.
Il a été introduit par
http://core.spip.org/trac/spip/changeset/7b84f9ecb2945a3d9bf6467baf3b8bb452356a62/ecrire/inc/import.php
mais ça marche en 2.0, je soupçonne donc plutôt
http://core.spip.org/trac/spip/changeset/239dc5b7aaf6f66f543d478988102f09e9f41f34
qui dit réparer un bug là-dessus, mais n'a visiblement pas vu celui-ci.

Au passage, j'ai voulu être plus précis en utilisant svn up -rXXX mais en 2.1 ça provoque l'erreur de fontion indéfinie sur compacte_head parce que l'extension correspondante ne suit pas. Ca c'est une régression dans l'outil de travail.

7

Le bug est plus vicieux que cela, car je viens encore de refaire le test d'import d'une base en version 14558 (exportée depuis SPIP 2.0) dans un SPIP 2.1 svn, et la restauration est bien complète y compris avec les auteurs.

Peut être que le bug est lié au timeout et à la reprise si c'est une grosse base dans ton cas test ?

Cédric

8

Non, j'ai réduit mon dump à 44Ko (2 auteurs, 1 rubrique, les types-doc et les meta) et ça le fait toujours.
Je te l'envoie perso.

Committo,Ergo:Sum

9

Donc effectivement, c'est moi qui testait mal, car j'avais raté le principal, à savoir que cela se produit quand le prefixe de la base
n'est pas spip_

Pour le coup, le bug était balot, mais je me demande si il n'est pas là depuis que j'ai ajouté cette fonctionnalité.

Le patch qui doit résoudre cela (enfin chez moi ça marche, si tant est que j'ai reproduit le bon test cette fois) :
http://core.spip.org/trac/spip/changeset/cd3c5cc52c49a61f79bfbe7a312544e5e3fcdf48

Cédric

10

Oui, ça remarche chez moi.

Committo,Ergo:Sum