[spip-dev] [spip dev] declarer_tables_objets_sql, help !

Dev
1

Bonjour,

J’essaye de réparer le fait qu’une installation vierge 2.3 n’installe pas spip_petitions, et fait donc buggé un peu le tout. L’erreur est lors de la création de la table, où id_article se prend et un auto_increment, et un DEFAULT ‘0’ NOT NULL, ce qui bien évidemment ne fonctionne pas.

Erreur 1067 de mysql: Invalid default value for ‘id_article’
CREATE TABLE IF NOT EXISTS p467_7.spip_petitions (
id_article bigint(21) DEFAULT ‘0’ NOT NULL auto_increment,

Je pense que j’ai mal compris, mais si dans la déclaration je met principale => ‘non’ à la place du ‘oui’ actuel pour la déclaration de spip_petitions, il ne devrait pas la considérée comme auxiliaires, et donc ne pas mettre auto_increment dans la requete de création ?
$tables[‘spip_petitions’] = array(
‘url_voir’=>‘controler_petition’,
‘url_edit’=>‘controler_petition’,
‘editable’=>‘non’,
‘principale’ => ‘non’,

Du coup le seul moyen que je trouve pour “réparer”, c’est de remettre l’ancienne déclaration et l’appel au pipeline dans plugin.xml de r43407

function petitions_declarer_tables_auxiliaires($tables_auxiliaires){
…
}

Ai-je mal compris le role de ‘principale’ dans declarer_tables_objets_sql ?

2

Bon, pour petitions, j’ai du coup réintroduit petitions_declarer_tables_auxiliaires
http://zone.spip.org/trac/spip-zone/changeset/44947

En espérant ne pas avoir fait de bêtises…

2011/2/25 Guy Cesaro <guy.cesaro@gmail.com>

3

Oui ça corrige mais tu as raison : le bug est dans la création de la table qui ne prends pas en compte le pipeline déclarer_tables_objets_sql

Cédric
envoyé depuis ma montagne

4

Ah ? J’avais l’impression que si, puisqu’il tentait de créer mais cela générait une erreur sql sur id_article à cause de l’auto_increment. En fait, c’est ce paramètre que je n’arrivais pas à virer lors de la création. Je pensais que mettre dans la déclaration ‘principale’ => ‘non’ pour la table spip_petitions, ça l’enleverait en déduisant que c’était une auxiliaire mais non ? Si ce n’est pas sur ce paramètre que ça doit jouer, on peut pas en ajouter un pour declarer les auxiliaires dans la fonction déclarer_tables_objets_sql ?

2011/2/25 cedric.morin@yterium.com <cedric.morin@yterium.com>

5

J’ai fait une première tentative pour réparer certains trucs sur “mots”. si quelqu’un veut bien vérifier que j’ai pas trop fait de bêtises ?
http://zone.spip.org/trac/spip-zone/changeset/44969/core/plugins/mots/base/mots.php

J’en ai profité pour noter 2, 3 trucs :
Dans le cadre d’une migration 2.1->2.3, il y a un problème pour l’extension site et les mots :
l’objet renseigné dans spip_mots_liens est site. Mais si on associe un mot avec le formulaire editer_liens, l’objet renseigné devient site dans spip_mots_liens . Donc petit soucis dans la declaration de syndic je pense ? ou dans la migration de mots ?

L’extension forum déclare

$interfaces[‘tables_jointures’][‘spip_forum’][]= ‘mots_liens’;
$interfaces[‘tables_jointures’][‘spip_forum’][]= ‘mots’;

Ce n’est pas à mots de déclarer ça ?
On ne devrait pas utiliser #FORMULAIRE_EDITER_LIENS pour les mots sur les forums ?

spip_resultats, la recherche, peut poser des soucis. Je ne sais pas si les résultats sont invalidés au bout d’un certain temps ou à l’institution d’un objet mais le fait de ne pas relancer la recherche pose problème :
Je fait une recherche sur “toto”, et je trouve des articles. Si je prends un article non trouvé et que je lui attribue le mot clé “toto”, la recherche ne l’incluera pas, elle va ressortir la première liste d’article, car spip_resultats ressort le même resultat ?! c’est un vrai soucis ça !

Enfin, toujours dans l’idée d’une migration 2.1->2.3, je me demande comment faire pour gérer les objets qui utilisent mots_objets, ou même agenda. La migration des mots semblent bien prise de tête si on veut quelque chose qui marche partout.

Voilà voilà…

6

Hello,
Je vais regarder cela des que j’ai un moment.
Mais comme pour les pétitions, je préférerai corriger le core pour que tout marche avec des déclarations standard sur déclarer_tables_objets_sql plutôt que de bidouiller les déclarations pour que ça marche en l’état.
Clairement le code des jointures de recherche est foireux et a reprendre.
Idem pour les installations de tables, il faut reprendre le code.
On est clairement dans en état transitoire mais c’est inévitable. Par contre évitons de revenir en arrière sur les déclarations de table dans les extensions, même si je comprends que ça t’embete que ce soir moyennement fonctionnel en l’état.
Lever les problèmes est déjà bien. Par contre je vais être peu réactif sur la semaine qui vient.

Cédric

7

2011/2/26 cedric.morin@yterium.com <cedric.morin@yterium.com>

Hello,
Je vais regarder cela des que j’ai un moment.
Mais comme pour les pétitions, je préférerai corriger le core pour que tout marche avec des déclarations standard sur déclarer_tables_objets_sql plutôt que de bidouiller les déclarations pour que ça marche en l’état.
Clairement le code des jointures de recherche est foireux et a reprendre.
Idem pour les installations de tables, il faut reprendre le code.
On est clairement dans en état transitoire mais c’est inévitable. Par contre évitons de revenir en arrière sur les déclarations de table dans les extensions, même si je comprends que ça t’embete que ce soir moyennement fonctionnel en l’état.
Lever les problèmes est déjà bien. Par contre je vais être peu réactif sur la semaine qui vient.

Cédric

Salut,
Désolé, dis-moi s’il faut revert pour ne pas embrouiller les développements en cours. Je continue de noter dans un coin les soucis quand j’en rencontre et j’arrête ces retours en arrières.
Passe une bonne semaine !

8

Il n'y a pas de soucis, c'est très bien de faire avancer et ça me mets la pression :stuck_out_tongue:

Cédric

9

J'en ai profité pour noter 2, 3 trucs :
Dans le cadre d'une migration 2.1->2.3, il y a un problème pour l'extension site et les mots :
l'objet renseigné dans spip_mots_liens est site. Mais si on associe un mot avec le formulaire editer_liens, l'objet renseigné devient site dans spip_mots_liens . Donc petit soucis dans la declaration de syndic je pense ? ou dans la migration de mots ?

l'un des deux est syndic je suppose ?

L'extension forum déclare
$interfaces['tables_jointures']['spip_forum']= 'mots_liens';
$interfaces['tables_jointures']['spip_forum']= 'mots';

Ce n'est pas à mots de déclarer ça ?

oui je suis en train de revoir ça pour permettre de declarer une jointure 'pour tous les objets' comme c'est typiquement le besoin pour les mots, documents...

On ne devrait pas utiliser #FORMULAIRE_EDITER_LIENS pour les mots sur les forums ?

a voir, mais les forum sont ici une interface publique, donc je ne pense pas que ce soit pertinent (en tout cas pour la redaction d'un message dans le public)
Après ce peut être une option pour modifier un message dans l'espace privé (modération par mot clé a destination du site public)

spip_resultats, la recherche, peut poser des soucis. Je ne sais pas si les résultats sont invalidés au bout d'un certain temps ou à l'institution d'un objet mais le fait de ne pas relancer la recherche pose problème :
Je fait une recherche sur "toto", et je trouve des articles. Si je prends un article non trouvé et que je lui attribue le mot clé "toto", la recherche ne l'incluera pas, elle va ressortir la première liste d'article, car spip_resultats ressort le même resultat ?! c'est un vrai soucis ça !

Non, il y a un petit cache de recherche de l'ordre de 600s je crois.
Mais par contre il faut revoir la structure de spip_resultats pour ressortir le nom de la table du hash et permettre ainsi de faire des recherches multi-objets plus facilement.

Enfin, toujours dans l'idée d'une migration 2.1->2.3, je me demande comment faire pour gérer les objets qui utilisent mots_objets

je ne sais pas quelle est la specificté de la table, je n'utilise pas. Mais il faut l'intégrer dans la migration. Mathieu saura surement comment faire.

, ou même agenda.

Je ne vois pas de probleme avec agenda par contre ?

La migration des mots semblent bien prise de tête si on veut quelque chose qui marche partout.

heu non, je ne pense pas. tout doit être migré dans spip_mots_liens, et il y aura du code a ré-écrire pour cela sur chaque plugin concerné.

Cédric

10

2011/2/26 <cedric.morin@yterium.com>

J’en ai profité pour noter 2, 3 trucs :
Dans le cadre d’une migration 2.1->2.3, il y a un problème pour l’extension site et les mots :
l’objet renseigné dans spip_mots_liens est site. Mais si on associe un mot avec le formulaire editer_liens, l’objet renseigné devient site dans spip_mots_liens . Donc petit soucis dans la declaration de syndic je pense ? ou dans la migration de mots ?

l’un des deux est syndic je suppose ?

Oui ! celui qui migre => syndic
celui qui est créer et détectée => site

L’extension forum déclare
$interfaces[‹ tables_jointures ›][‹ spip_forum ›]= ‹ mots_liens ›;
$interfaces[‹ tables_jointures ›][‹ spip_forum ›]= ‹ mots ›;

Ce n’est pas à mots de déclarer ça ?

oui je suis en train de revoir ça pour permettre de declarer une jointure ‹ pour tous les objets › comme c’est typiquement le besoin pour les mots, documents…

Chouestte.

On ne devrait pas utiliser #FORMULAIRE_EDITER_LIENS pour les mots sur les forums ?

a voir, mais les forum sont ici une interface publique, donc je ne pense pas que ce soit pertinent (en tout cas pour la redaction d’un message dans le public)
Après ce peut être une option pour modifier un message dans l’espace privé (modération par mot clé a destination du site public)

Ok compris !

spip_resultats, la recherche, peut poser des soucis. Je ne sais pas si les résultats sont invalidés au bout d’un certain temps ou à l’institution d’un objet mais le fait de ne pas relancer la recherche pose problème :
Je fait une recherche sur « toto », et je trouve des articles. Si je prends un article non trouvé et que je lui attribue le mot clé « toto », la recherche ne l’incluera pas, elle va ressortir la première liste d’article, car spip_resultats ressort le même resultat ?! c’est un vrai soucis ça !

Non, il y a un petit cache de recherche de l’ordre de 600s je crois.
Mais par contre il faut revoir la structure de spip_resultats pour ressortir le nom de la table du hash et permettre ainsi de faire des recherches multi-objets plus facilement.

Enfin, toujours dans l’idée d’une migration 2.1->2.3, je me demande comment faire pour gérer les objets qui utilisent mots_objets

je ne sais pas quelle est la specificté de la table, je n’utilise pas. Mais il faut l’intégrer dans la migration. Mathieu saura surement comment faire.

, ou même agenda.

Je ne vois pas de probleme avec agenda par contre ?

Effectivement ! Je vois des problèmes là où y en a pas. En fait, ils pourront chargés mots_maj_tables_liaisons pour leur propre upgrade ?