[spip-dev] aïe ! parse error ça fait mal

http://www.spip-contrib.net/recherche.php3?recherche=m�mo

L'erreur qui s'affiche est tout sauf explicite :

Parse error: parse error in
/var/www/shim/spipcontrib/Web/inc-public.php3(157) : eval()'d code on line 53

-- Fil

Pas de panique, le source est quand même dans le répertoire cache,
et c'est le dernier créé.

esj

>Parse error: parse error in
>/var/www/shim/spipcontrib/Web/inc-public.php3(157) : eval()'d code on
>line 53

Pas de panique, le source est quand même dans le répertoire cache,
et c'est le dernier créé.

Je suppose qu'il est impossible de gérer cette erreur, pour lui rendre forme
humaine ?

-- Fil

> >/var/www/shim/spipcontrib/Web/inc-public.php3(157) : eval()'d code on
> >line 53
>
> Pas de panique, le source est quand même dans le répertoire cache,
> et c'est le dernier créé.

Je suppose qu'il est impossible de gérer cette erreur, pour lui rendre forme
humaine ?

Bon : j'ai ajouté une ligne de debug juste au-dessus de l'eval, ligne 153 :
if ($GLOBALS['auteur_session']['login'] == 'filou') echo $texte;

pour m'afficher $texte, et le code en question, ligne 53, vaut :

                                <?
                                $NbResults++; // bête incrémentation (basique mais efficace)
                                if ($MaxPts==0) $MaxPts = #POINTS; //
                                
                                ?>

#POINTS n'a donc pas été renseigné par la boucle.

-- Fil

2 aspects:

- PHP begaie: " parse error: parse error " ! c'est lui qui n'est pas très humain;
d'expérience c'est un mauvais parenthésage (il pourrait le suggérer d'ailleurs)

- mon compilo est en test, c'est le moins qu'on puisse dire; une fois stabilisé,
ces messages seront aussi rares qu'avec l'ancien.

esj

#POINTS n'a donc pas été renseigné par la boucle.

Si j'ajoute dans inc-vrac-squel :

case 'POINTS':
        $code = '$PileRow[$SP]["points"]';
        break;

ça marche ; mais je suppose que ce n'est pas la bonne méthode :slight_smile:

-- Fil

Le squelette que tu indiquais dans le mail précédent:
http://www.spip-contrib.net/article.html
ne contient pas :
      <?
                                 $NbResults++; // bête incrémentation (basique mais efficace)
                                 if ($MaxPts==0) $MaxPts = #POINTS; //

                                 ?>

je suppose que ça devait être dans un des inclus.
Tu peux me l'envoyer ?

esj

Le squelette que tu indiquais dans le mail précédent:
http://www.spip-contrib.net/article.html
ne contient pas :
     <?
                                $NbResults++; // bête incrémentation
(basique mais efficace)
                                if ($MaxPts==0) $MaxPts = #POINTS; //

                                ?>

Les #POINTS sont les points de la recherche ; il s'agit du squelette
recherche.html

L'autre bug, celui de article.html, était lié à la boucle récursive
_documents

-- Fil

Les #POINTS sont les points de la recherche ; il s'agit du squelette
recherche.html

Si j'ajoute dans inc-vrac-squel :

case 'POINTS':
        $code = '$PileRow[$SP]["points"]';
        break;

ça marche ; mais je suppose que ce n'est pas la bonne méthode :slight_smile:

Bon ok, j'ai en effet zappé le fait que les tables de recherche
contiennent des champs qui sont aussi des balises SPIP.

Mais du coup une question: pourquoi ces tables ne déclarent-elles pas
leur champ id_article, id_breve etc comme PRIMARY KEY ?
Ca me paraitrait sohaitable d'une part, et
ça me faciliterait la vie de l'autre.

L'autre bug, celui de article.html, était lié à la boucle récursive
_documents

oui, je renvoie une version avec ancienne sémantique des doublons,
on va voir si le pb est lié.

esj

Bon ok, j'ai en effet zappé le fait que les tables de recherche
contiennent des champs qui sont aussi des balises SPIP.

Les tables de recherche ?? De quoi parles-tu ? Je ne comprend rien.

Quand on fait une recherche, on a une requête sur la table spip_articles,
par exemple, avec une définition de "SUM(...) AS points".

C'est ce "points"-là qu'il faut récupérer et afficher.

-- Fil

Bon ok, j'ai en effet zappé le fait que les tables de recherche
contiennent des champs qui sont aussi des balises SPIP.

Les tables de recherche ?? De quoi parles-tu ? Je ne comprend rien.

Je parle des tables qui s'appellent index_articles, index_auteurs etc
qui sont utilisées en cas de critère "recherche" dans le code du compilo

Quand on fait une recherche, on a une requête sur la table spip_articles,
par exemple, avec une définition de "SUM(...) AS points".

Bah non, ce n'est pas directement dans la table spip_articles qu'on va
chercher ça mais dans la table index_articles.

C'est ligne 52 de inc-arg-squel, et 303 dans l'ancien compilo (inc-calcul-squel).

C'est ce "points"-là qu'il faut récupérer et afficher.

Non ?

esj

>Les tables de recherche ?? De quoi parles-tu ? Je ne comprend rien.

Je parle des tables qui s'appellent index_articles, index_auteurs etc
qui sont utilisées en cas de critère "recherche" dans le code du compilo

>Quand on fait une recherche, on a une requête sur la table
>spip_articles,
>par exemple, avec une définition de "SUM(...) AS points".

Bah non, ce n'est pas directement dans la table spip_articles qu'on va
chercher ça mais dans la table index_articles.

C'est ligne 52 de inc-arg-squel, et 303 dans l'ancien compilo
(inc-calcul-squel).

>C'est ce "points"-là qu'il faut récupérer et afficher.

Non ?

Non, c'est leur total pour un article ! "SUM(...) AS points"

-- Fil

Non, c'est leur total pour un article ! "SUM(...) AS points"

Bon, je commite mon patch mais je suis presque sûr que dans ton modèle de
gestion des balises #XXXXX on n'est pas censés faire comme ça, c'est très
goret :slight_smile:

-- Fil

ecoute, tu veux pas aller regarder le code à l'endroit indiqué ?
Tu insistes tellement que je me demande s'il n'y a pas 2 utilisations
du champ Point (sans rien tirer par les cheveux ....)

esj

Tu insistes tellement que je me demande s'il n'y a pas 2 utilisations
du champ Point (sans rien tirer par les cheveux ....)

Bon, mais en fait on est d'accord : on va bien le rechercher dans les tables
d'indexation (ce que tu dis en parlant de tables de recherche), mais en en
faisant la somme (ce que je dis). Donc ce n'est pas tout à fait un champ,
mais le résultat d'une opération (ce que je voulais dire), et c'est bien
ligne 52 de inc-arg-squel (ce que tu disais).

-- Fil

Bon, ouf, mais alors du coup je repose ma question pourquoi les tables index_*
ne sont pas déclarées en PRIMARY_KEY ?

esj

Bon, ouf, mais alors du coup je repose ma question pourquoi les tables
index_* ne sont pas déclarées en PRIMARY_KEY ?

Je n'en sais rien ; pourquoi devraient-elles l'être ?

-- Fil

http://dev.mysql.com/doc/mysql/en/CREATE_TABLE.html dit:

  • A PRIMARY KEY is a unique KEY where all key columns must be defined as NOT NULL. If they are not explicitly declared as NOT NULL, MySQL will declare them so implicitly (and silently). A table can have only one PRIMARY KEY. If you don't have a PRIMARY KEY and an application asks for the PRIMARY KEY in your tables, MySQL returns the first UNIQUE index that has no NULL columns as the PRIMARY KEY.
  • In the created table, a PRIMARY KEY is placed first, followed by all UNIQUE indexes, and then the non-unique indexes. This helps the MySQL optimizer to prioritize which index to use and also more quickly to detect duplicated UNIQUE keys.

esj

Bon, ouf, mais alors du coup je repose ma question pourquoi les tables
index_*
ne sont pas déclarées en PRIMARY_KEY ?

Au lieu de citer des bouts de doc MySQL, fais un ALTER TABLE vite fait
et tu comprendras qu'ajoute une clé primaire double la taille des
fichiers d'index (et ralentit les mises à jour d'indexation). Tout en
n'apportant rien dans l'usage quotidien.

a+

Sur le fond : ce qui devrait selon toi être un PRIMARY_KEY dans la table
spip_index_articles, c'est quoi ? Car une *table* n'est pas une
primary *key* ; une prmiary key, c'est un champ (ou un complexe de champs).

Tu veux mettre en primary les (id_article, hash) ?

Tu vas y gagner quoi (vitesse, combien ?)

Tu vas y perdre quoi (espace disque, combien ?)

-- Fil