[spip-dev] tables externes - boucles imbriqu?es

Bonjour, j'ai un pb avec une boucle qui fonctionnait il y a peu...

<ul><b>GROUPES</b>
<BOUCLE_GI(JPK:JPK_GROUPES){tout}{par nom}>
<li>#ID_GROUPE - #NOM</li>
<ul>Membre(s) :
<BOUCLE_GI_A(JPK:JPK_GROUPES_AUTEURS){id_groupe=#ID_GROUPE}>
<li>#ID_AUTEUR</li>
</BOUCLE_GI_A>
</ul>
</BOUCLE_GI>
</ul>

voici ma défiition des tables :
// ==== TABLES JPK ====
$jpk_groupes = array(
"id_groupe" => "bigint(21) auto_increment",
"nom" => "varchar(30)",
"description" => "varchar(250)",
"actif" => "smallint(1)"
);
$jpk_groupes_key = array(
  "PRIMARY KEY" => "id_groupe",
  "KEY id_groupe" => "id_groupe"
);

$jpk_groupes_auteurs = array(
"id_groupe" => "bigint(21) NOT NULL DEFAULT '0'",
"id_auteur" => "bigint(21) NOT NULL DEFAULT '0'",
"dde_acces" => "smallint(1)"
);
$jpk_groupes_auteurs_key = array(
"KEY id_groupe" => "id_groupe",
"KEY id_auteur" => "id_auteur"
);

$jpk_groupes_acces = array(
"id_groupe" => "bigint(21) NOT NULL default '0'",
"id_rubrique" => "bigint(21) NOT NULL default '0'",
"id_article" => "bigint(21) default NULL",
"dtdb" => "date default NULL",
"dtfn" => "date default NULL"
);

$jpk_groupes_acces_key = array(
"KEY id_groupe" => "id_groupe",
"KEY id_rubrique" => "id_rubrique",
"KEY id_auteur" => "id_auteur"
);

$tables_jpk['jpk_groupes'] =
    array('field' => &$jpk_groupes, 'key' => &$jpk_groupes_key);

$tables_jpk['jpk_groupes_auteurs'] =
    array('field' => &$jpk_groupes_auteurs, 'key' =>
&$jpk_groupes_auteurs_key);

$tables_jpk['jpk_groupes_acces'] =
    array('field' => &$jpk_groupes_acces, 'key' => &$jpk_groupes_acces_key);

$GLOBALS['tables_des_serveurs_sql']['JPK']=&$tables_jpk;

//========================

lorsque cette boucle est calculé par le compilo, j'ai le message d'erreur
sivant :
Fatal error: Call to undefined function: array() in
e:\@jpk\internet\spip-svn\spip\ecrire\inc_abstract_sql.php3 on line 108

voici la ligne incriminée...
104 function spip_abstract_showtable($table, $serveur='')
105 {
106 $f = (!$serveur ? 'spip_mysql_showtable' :
107 spip_abstract_serveur('spip_' . $serveur . '_showtable', $serveur));
108 return $f($table);
109 }

//========================
Note: tout fonctionne bien tant que je ne tente pas d'imbriquer les
boucles...
où est l'erreur ???

le problème semble être au niveau de {id_groupe=#ID_GROUPE}

Qui, dans mon cas, ne doit pas correspondre aux tables des mot clés

merci d'avance pour votre aide...

Bonjour

J'essai de faire tourner sans succès une jointure avec des tables non-spip. La procédure est décrite ici:
http://listes.rezo.net/archives/spip-core/2005-08/msg00006.html

J'ai inséré dans ma base SPIP les tables suivantes :

    - objet (avec "no_objet" comme clé primaire)
    - categorie (avec "no_categorie" comme clé primaire)
    - objet_cat (contenant les champs "no_objet" et "no_categorie")

Jusque là tout va bien en ce sens que SPIP a reconnait toutes les nouvelles tables sans avaoir à les déclarer dans mes_fonctions.php3 et je peux en extraire des données avec des boucles simple.

Ça se gâte avec les jointures de table. Avec cette boucle :

<BOUCLE_objet_description(OBJET){no_objet}>
                [(#NOM)]
        <BOUCLE1(CATEGORIE objet_cat){no_objet}>
                #NOM_CATEGORIE
        </BOUCLE1>
</BOUCLE_objet_description>

j'obtiens cette erreur :

    * Erreur(s) dans le squelette
          o Erreur sur le site,
          o <BOUCLE1>(categorie)
            *Erreur MySQL*
            SELECT categorie.nom_categorie FROM categorie AS categorie
            WHERE categorie.no_objet = '1'
            *Champ 'categorie.no_objet' inconnu dans where clause*
            </BOUCLE1>

Ai-je la bonne syntaxe où est-ce un bug ?

Merci

Pierre

Oui, je n'avais pas eu le temps de programmer les jointures sur tables externes.
Pas le temps de vérifier, mais ca semble déjà mieux.

Déesse A.

J'ai testé avec les derniers changement sur SVN (revision 4843).

Malheureusement toujour le même message d'erreur.

    * Erreur(s) dans le squelette
          o Erreur sur le site,
          o <BOUCLE1>(categorie)
            *Erreur MySQL*
            SELECT categorie.nom_categorie FROM categorie AS categorie
            WHERE categorie.no_objet = '1'
            *Champ 'categorie.no_objet' inconnu dans where clause*
            </BOUCLE1>

Pierre

Déesse A. wrote:

Ta description est-elle complete ? Car si tu n'écris pas les 3 tables dans boucle1:
         <BOUCLE1(CATEGORIE objet_cat objet){no_objet}>
alors Spip ne peut faire une jointure entre Categorie et object_cat que si elles ont elles-meme sun champ de meme nom.

Déesse A.

Déesse A. wrote:

Ta description est-elle complete ? Car si tu n'écris pas les 3 tables dans boucle1:
        <BOUCLE1(CATEGORIE objet_cat objet){no_objet}>
alors Spip ne peut faire une jointure entre Categorie et object_cat que si elles ont elles-meme sun champ de meme nom.

Il manquait en effet objet dans le choix des tables mais ça ne fonctionne toujours pas avec la boucle corrigée :
<BOUCLE_objet_description(OBJET){no_objet}>
                [(#NOM)]
        <BOUCLE1(CATEGORIE objet_cat objet ){no_objet}> #NOM_CATEGORIE
        </BOUCLE1>
</BOUCLE_objet_description>

Pierre

Je précise. Avec la boucle contenant toutes les tables, j'obtient le même message d'erreur qu'auparavant :

    * Erreur(s) dans le squelette
          o Erreur sur le site,
          o <BOUCLE1>(categorie)
            *Erreur MySQL*
            SELECT categorie.nom_categorie FROM categorie AS categorie
            WHERE categorie.no_objet = '1'
            *Champ 'categorie.no_objet' inconnu dans where clause*
            </BOUCLE1>
          o

Pierre

Pierre Bourgeois wrote:

Je n'observe pas ce comportement avec ce que tu donnes comme informations.
Donne la description complete de tes tables.

Déesse A.

Voici la structure des 3 tables :

Voici la structure des 3 tables :

ok, j'ai compris. C'est une limitation qui devrait disparaitre, mais pour l'instant l'ordre des tables de jointures est significatif. Au lieu de:

        <BOUCLE1(CATEGORIE objet_cat objet ){no_objet}>

ecris

     <BOUCLE1(CATEGORIE objet objet_cat ){no_objet}>

Déesse A.

Hmmm... L'ordre des tables de jointure ne change rien... J'obtiens toujours le même message d'erreur.

Merci de ton aide.

Pierre

Déesse A. wrote:

Ah oui, il y avait aussi le cas non prévu de PRIMARY KEY à valeurs multiples.

La prochaine fois donne tout de suite tout le texte de ton exemple, ça va beaucoup plus vite...

Déesse A.

Ça marche 10/10 ! Merci beaucoup !

Déesse A. wrote:

La prochaine fois donne tout de suite tout le texte de ton exemple, ça va beaucoup plus vite...

C'est noté.

Pierre

Bonjour,

Je veux afficher le contenu d'un champs qui se nomme "public". Donc je mets la balise #PUBLIC dans ma boucle et ça s'affiche bien. Le problème est qu'en plus du contenu affiché, la page Web affiche aussi ce message :

    * Erreur(s) dans le squelette
          o Aucun squelette n'est disponible...,

Si je donne un autre nom au champ "public" ça résoud le problème. Le hic c'est que la table en question est utilisé par une autre application (un référenceur de métadonnées d'objet d'apprentissage).

Voici la boucle utilisée:

<BOUCLE_principale(ARTICLES){id_article}>
<h1>#TITRE</h1>
<BOUCLE_objet_description(OBJET){id_article=#_principale:ID_ARTICLE}>
[Audience/public primaire : (#PUBLIC)]
</BOUCLE_objet_description>
</BOUCLE_principale>

Voici la structure de la table qui contient le champs "public" :

CREATE TABLE `objet` (
  `no_objet` int(11) NOT NULL auto_increment,
  `id_article` bigint(12) NOT NULL default '0',
  `nom_util` varchar(50) NOT NULL default '',
  `nom` tinytext NOT NULL,
  `lien` tinytext NOT NULL,
  `fichier` tinyint(4) NOT NULL default '0',
  `lien_miroir` tinytext NOT NULL,
  `description` text NOT NULL,
  `mots` text NOT NULL,
  `image` varchar(50) NOT NULL default '',
  `materiel` varchar(50) NOT NULL default '',
  `public` varchar(50) NOT NULL default '',
  `age` varchar(50) NOT NULL default '',
  `auteur_nom` tinytext NOT NULL,
  `auteur_courriel` tinytext NOT NULL,
  `auteur_org` tinytext NOT NULL,
  `editeur` tinytext NOT NULL,
  `format` tinytext NOT NULL,
  `spec_tech` text NOT NULL,
  `version` varchar(50) NOT NULL default '',
  `langue` varchar(5) NOT NULL default '',
  `cout` varchar(10) NOT NULL default '',
  `copyright` varchar(10) NOT NULL default '',
  `copyright_restriction` text NOT NULL,
  `nbr_consultations` int(11) NOT NULL default '0',
  `date_ajout` datetime NOT NULL default '0000-00-00 00:00:00',
  `date_modif` datetime NOT NULL default '0000-00-00 00:00:00',
  `date_publication` datetime NOT NULL default '0000-00-00 00:00:00',
  PRIMARY KEY (`no_objet`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=2 ;

Les entrés au log :

Oct 10 14:03:21 127.0.0.1 (pid 328) Erreur squelette: Aucun squelette <b></b> n'est disponible... | (article.html)
Oct 10 14:03:21 127.0.0.1 (pid 328) calcul inclus (): (, delais=, GET)
Oct 10 14:03:21 127.0.0.1 (pid 328) calcul skel squelettes/article.html (0.03s)
Oct 10 14:03:21 127.0.0.1 (pid 328) calcul (0.02s): CACHE/9/ticle%3Fid_article%3D1.b98ba2dc.gz
Oct 10 14:03:21 127.0.0.1 (pid 328) calcul skel formulaires/formulaire_admin.html (0.07s)
Oct 10 14:03:21 127.0.0.1 (pid 328) calcul inclus (0.08s): (formulaire_admin, delais=0, GET)

C'est assez comique. Lorsqu'une entite #Quelquechose n'a pas de fonction balise_quelquechose de définie, Spip va regarger s'il existe un fichier inc-quelquechose.php3 qui est censé la définir (toutes les balises de formulaires sont programmées ainsi), et en dernier ressort il va regarder dans les tables SQL. En l'occurrence, ta balise #PUBLIC a provoqué le chargement du fichier inc-public.php3 qui fait bien autre chose que de définir cette balise.

Il y a donc des fichiers à renommer. Lesquels ? Ceux des balises autochargeables (inc-formulaire*) ou inc-public lui-même ? On est passé sous Subversion justement pour pouvoir renommer sans perdre l'historique des révisions, il est temps de s'y mettre. Dans la mesure où tous les fichiers inc* (hors balises autochargeables) devraient etre dans un répertoire d'inclusion partageable par plusieurs versions de Spip, je pense que le mieux est de déménager tous les
fichiers inc* de la racine auprès de leurs congénères ecrire/inc_*, en regardant à la petite cuillère la centaine d'occurrence de inc-* dans le code pour faire les adaptations qui s'imposent. Il y a d'autres pistes, mais celle-ci me parait la plus immédiate. Le débat est ouvert.

Déesse A.

Il y a donc des fichiers à renommer. Lesquels ? Ceux des balises
autochargeables (inc-formulaire*) ou inc-public lui-même ? On est

Ne renomme pas inc-public ni inc_version, ce sont les deux portes d'entrée
principales de la quesi totalité des contribs.

Pour le reste, je continue de penser que la recherche systématique de
"inc-$x" ou de constructions de ce type ne vaut pas une vraie gestion des
plugins (que j'aurais bien du mal à définir cela dit).

-- Fil

Tout le pb est là.
Pour le pb du jour, je pense qu'il suffit de retirer "." de la définition par défaut de SPIP_PATH.
Cela dit, on approche d'une architecture où Spip serait installé en un seul exemplaire chez un hébergeur, chacun n'ayant plus que des contribs perso et autres dans son répertoires, et là il faudra bien remplacer "include('inc-public.." par une inclusion précisant un chemin d'accès.

Déesse A.

de mon côté , c'est corrigé,

le boucle

<b>GROUPES</b>

<BOUCLE_GI(JPK:JPK_GROUPES){tout}{par nom}>
<li>#ID_GROUPE - #NOM</li>
<ul>Membre(s) :
<BOUCLE_GI_A(JPK:JPK_GROUPES_AUTEURS){id_groupe=#ID_GROUPE}>
<li>#ID_AUTEUR</li>
</BOUCLE_GI_A>
</ul>
</BOUCLE_GI>
</ul>

mais il est vrai que je n'avais pas tenté la nouvelles version des joints
entre tables...

merci

effectivement une vrai gestion des plug-ins serait le plus indispensable...

qu'est-ce que ce terme anglais désigne, sinon un moyen d'étendre la fonctionnalité d'un programme en allant charger des fonctionnalités supplémentaires dans un ou plusieurs fichiers portant un nom conventionnel ? L'informatique est maintenant une vieille discipline qui retombent bien souvent sur les mêmes techniques,
masquer ce fait par du vocabulaire nouveau n'y change rien. Alors, je ne vois pas ce qu'il y a d'indispensable puisque la mécanique existe déjà (une balise indéfinie provoque la recherche de sa définition dans les fichiers du site), en revanche il devient vraiment indispensable d'avoir un répertoire où figure le noyau de Spip et d'autres où figurent les extensions. C'est le problème posé par la 1.9 qui permet d'attaquer n'importe quelle table SQL, les pbs de ce genre
vont se multiplier.

Déesse A.