Recherche avancée

Sur d’autres sites (9883)

• Evolution #3638 (Nouveau) : Utiliser la rechercher Fulltext par défaut pour le critère {recherche}

  7 janvier 2016, par Gilles VINCENT

  Suite à la discussion entammée sur spip-dev, je suggère d’utiliser la recherche Fulltext par défaut, au lieu des REGEXP actuelles
  http://thread.gmane.org/gmane.comp.web.spip.devel/66780

  Par défaut, recherche génère des requêtes des type REGEXP, ce qui n’est utile que si des utilisateurs font des recherches avec des expressions régulières, ce qui n’est pas le cas. Depuis le commit r21697 les tables ont installées par défaut au format MyISAM (demande #2727). SPIP gagnerait donc à utiliser les recherches en Fulltext.

  Analyse détaillée du problème faite par Remi (root@lautre.net) :

  Le problème c’est que ce type de requête est généré dès lors qu’il y a un
  espace dans la recherche et les requêtes REGEXP n’utilisent pas les index.

  Donc ça ne concerne pas que les utilisateurs qui recherchent des
  expressions régulières.

  Pour une recherche aussi bête que "chercher un mot" ça recherche
  REGEXP sur chaque colonne de la table
  spip_articles. Evidemment ça renvoie tous les articles contenant "un".

  Un exemple particulièrement inefficace : 51s pour faire une recherche sur 2
  mots sans avoir la certitude que les 2 mots ne s’y trouvent.

  1. Query_time : 51.073814 Lock_time : 0.018906 Rows_sent : 16363 Rows_examined : 36816

  SELECT t.id_article, t.surtitre, t.titre, t.soustitre, t.chapo, t.texte,
  t.ps, t.nom_site, t.url_site, t.descriptif FROM `xxxxxx`.spip_articles AS t
  WHERE t.surtitre REGEXP ’Etats unis|Etats|unis’ OR t.titre REGEXP ’Etats
  unis|Etats|unis’ OR t.soustitre REGEXP ’Etats unis|Etats|unis’ OR t.chapo
  REGEXP ’Etats unis|Etats|unis’ OR t.texte REGEXP ’Etats unis|Etats|unis’
  OR t.ps REGEXP ’Etats unis|Etats|unis’ OR t.nom_site REGEXP ’Etats
  unis|Etats|unis’ OR t.url_site REGEXP ’Etats unis|Etats|unis’ OR
  t.descriptif REGEXP ’Etats unis|Etats|unis’ ;

  Ici, ça me renvoie les articles qui contiennent "punissons",
  "réunis".

  A ce niveau, un bête like me met "que" 5s :

  SELECT * from (select *, concat( t.surtitre, t.titre, t.soustitre,
  t.chapo, t.texte, t.ps, t.nom_site, t.url_site, t.descriptif) search from
  spip_articles t) s WHERE s.search like ’%unis%’ or s.search like
  ’%Etats%’ ;

  Mais honnêtement 5s, ce n’est pas non plus acceptable.

  Mais s’il vous faut mettre un truc par défaut autre que du fulltext,
  utilisez LIKE sur la chaine à rechercher. Ca ira plus vite et ça vous
  renverra des résultats plus cohérents.

  Remi

• Anomalie #3647 : #INTRODUCTION

  11 janvier 2016, par Ivan Lewkowitz

  Hello Franck, désolé, voici plus de détails :

  Il s’agit d’un Spip 3.0.21 mis à jour en 3.1 via Spip_loader.
  J’ai suivi les indications de maj. Les plugins sont compatibles (couteau suisse).
  Base de données : MySQL (exportée du site online via l’admin de Spip et réimportée en local, toujours via l’admin Spip, même version évidemment). Le fichier se termine en .sqlite (et non .dump ou autre).
  Le codage de la base est tout en utf-8, idem pour le site lui-même.

  Online, le site est en Spip 3.1 et Php 5.2 (module Apache) alors que dans Mamp, c’est Php 5.6.10 qui tourne (ou Php 7 au choix). Quand on passe d’une version à l’autre de Php en local, la première balise #INTRODUCTION est ignorée (le DIV accueillant l’intro est vide au lieu d’afficher un paragraphe).
  Ça c’est pour l’intro dans une boucle ARTICLES.
  

  
  [(#INTRODUCTION800|liens_ouvrants|propre)]
  

  Mais bizarrement, j’appelle aussi l’intro en survol sur des titres d’articles plus loin, et ça fonctionne sans problème :
  

  Donc… mystère. Donc pour résumer ma première balise intro ne saute qu’en local et avec Php 7 (donc rien de dramatique). J’ai pas essayé d’activer Php 7 chez mon hébergeur ; c’est proposé en beta encore.
  A ta dispo.

• Révision 22875 : Déplantage de la balise #RANG quand on a déclaré autre chose qu’un simple champ p...

  4 mars 2016, par rastapopoulos@spip.org

  On garde exactement le même fonctionnement qu’avant avec un "AS titre_rang" rajouté. Mais on fait deux tests au lieu d’un seul :
  - d’abord on cherche le titre en se disant que "lang" est défini AVANT
  - et si on ne trouve pas, là on prend depuis le début
  Mais dans les deux cas, vu que c’est séparé en deux, et qu’on cherche "lang" explicitement et pas une virgule toute seule : on peut donc prendre tout caractère pour le titre, y compris les virgules qu’il y aurait dans des fonctions.

  Cela gère donc bien tous les cas, enfin de toute façon plus de cas qu’avant.