Recherche avancée

Sur d’autres sites (5293)

• 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

• Evolution #3639 (Nouveau) : option pour le filtre |heures_minutes pour avoir version courte

  8 janvier 2016, par Maïeul Rouquette
  [(#DATE|heures_minutes)]

  
  affiche "20h25min"

  il serait bon d’avoir

  [(#DATE|heures_minutes{abbr})]

  Pour avoir "20h25"

  Exemple d’amélioration du code
  

  function heures_minutes($numdate,$forme='') {    
 if (forme !='abbr') {      
   return _T('date_fmt_heures_minutes', array('h' => heures($numdate), 'm' => minutes($numdate)));    
 }
 else {
    return _T('date_fmt_heures_minutes_court', array('h' => heures($numdate), 'm' => minutes($numdate)));    
 }
}

• Anomalie #3607 (Nouveau) : Problème de compatibilité avec mysql 5.7 pour SPIP 3.1

  28 novembre 2015, par Gilles VINCENT

  SPIP utilise un format non valide pour les dates par défaut.

  Exemple de déclaration pour spip_articles :
  `date_redac` datetime NOT NULL DEFAULT ’0000-00-00 00:00:00’,

  Il faut :
  - soit enlever la date par défaut et s’assurer que les dates sont toujours renseignées (ce qui n’est pas souhaité dans beaucoup de cas)
  - soit enlever en plus le NOT NULL et traiter en conséquence dans les filtres de date.

  Cela risque d’introduire des problèmes de compatibilité, et donc je la propose pour une future version majeure