[pierrepercee]

Bon, le loup est revenu...

Problème à l'import de la table sur un hébergement pro 2014 OVH -

#1214 - The used table type doesn't support FULLTEXT indexes

Les tables de type InnoDB ne supportent pas l'indexation FULLTEXT avant la version Mysql....

Je jette un oeil en local et bingo:

Certaines tables du module Cgcalendar sont en Innodb et toutes les tables du module LISE aussi = une palanquée d'em###des à prévoir en fonction des hébergements etc...
On a déjà vu ça par le passé.

Quelqu'un peut jeter un oeil sur une installation fraiche en ligne sur du 2.1.3 ?

Si c'est vérifié quelqu'un peut-il reporter le problème à Calguy et au développeur de LISE

[jce76350]

>Quelqu'un peut jeter un oeil sur une installation fraiche en ligne sur du 2.1.3 ?
Quelle est la question ? vérifier quoi ?

[Ouik]

C'est explicitement dit dans les nouvelles versions de CGCalendar : "New installs use InnoDB instead of MyISAM which allows for data integrity." C'est donc voulu.

Il n'y a pas une histoire de compatibilité de version de Mysql d'après ce que tu écris ?

[pierrepercee]

Bonjour JCE,

Y a plus grand chose à vérifier puisque

C'est explicitement dit dans les nouvelles versions de CGCalendar : "New installs use InnoDB instead of MyISAM which allows for data integrity." C'est donc voulu.

Je parlais de vérifier le type mime des tables.

Le bon fonctionnement dépend donc effectivement de la version de Mysql utilisée (si inférieure à 5.6 ça passe pas...). Juste comme ça, c'est le cas des plan pro OVH 2014, des anciens plans persos migrés, des 90 plans non migrés....
En mutualisé il n'y a guère que les offres performances qui proposent du 5.6 ou du 5.7 en sqlprivé.

[airelibre]

Pour l'heure, le plus simple est alors d'installer une ancienne version de CGCalendar puis faire la mise à jour - les tables devraient alors rester en MyIsam dans l'attente d'une mise à jour de MySQL

[pierrepercee]

Bonjour Airlibre,

Bigre, sauf que ça plante durement les mises à jour à partir d'anciennes versions : c'est signalé sur le bugtracker, d'ailleurs j'ai indiqué que probablement ça ne concernait que Windows mais c'est faux, c'est valable en ligne aussi. D'ici à ce que le plantage ne tienne au type de tables....
Donc pour l'heure faut oublier cette solution ...
C'est aussi dispo ici : bug mise à jour
Sur la forge : c'est ici
Pour un truc dument testé....

J'ai changé le type de la table pour MyIsam dans le dump avant importation: cela s'appelle du bricolage....
Après 2 heures à tenter de bricoler un csv à partir d'un export de la table fait sous PHPMyadmin, sans résultat (échec avec erreurs multiples lors de l'importation sans que la nature de ces erreurs ne soit précisée: ça importe bien les événements mais ça fout un bordel pas possible sur les dates), bien qu'ayant suivi scrupuleusement les infos du fichier d'aide, j'en ai eu un peu marre !
Résultat suppression du module et import à la main des 120 entrées: un travail passionnant.....

Faudrait voir ça avec CG et aussi pour LISE.

[jce76350]

tu dis

Le bon fonctionnement dépend donc effectivement de la version de Mysql utilisée (si inférieure à 5.6 ça passe pas...).

je ne comprends pas j'ai des versions mysql 5.5.49 ou 5.5.44. InnoDB est bien OK sur des installations aussi bien v2 que 1.12

[pierrepercee]

C'est pas moi qui le dit, c'est la doc officielle : "#1214 - The used table type doesn't support FULLTEXT indexes"
Après il s'agit de l'import d'un dump fait sous Wamp en version 5.6.17 et pas de l'installation, mise à jour.
En gros dans des environnements aussi hétérogènes et lorsque l'on connaît les effets de bord possible d'un mauvais type mime pour une table donnée je ne sais pas si la vérification de "data integrity" doit prendre le pas sur...


Pour l'heure je poursuis ma tache gratifiante ! Je suis charrette et ça me tombe dessus...
Y aura bien une petite mise à jour de CGcalendar un de ces jours.

[jce76350]

>#1214 - The used table type doesn't support FULLTEXT indexes
C'est uniquement pour cette table qui contient FULLTEXT qu'il suffit de passer en MyISAM

[pierrepercee]

JCE,

Oui, d'ailleurs si tu m'as bien lu c'est fait.... cela fonctionne, avec quelles conséquences et effet de bord pour la suite, je n'en sais rien .

Le débat est vieux de plus de trois ans maintenant , du coup toutes les tables avaient été passées en MyIsam. Je pensais que cela constituait une sorte de "jurisprudence raisonnable" si l'on se remémore l'énergie qui avait été nécessaire pour faire admettre une simple évidence et la "grande délicatesse" des reproches faits à celui qui avait "levé le lièvre" en l’occurrence moi.

Dans 2 ans c'est clair, tous les hébergeurs auront opté pour Mysql 5.6 et le problème ne se posera plus.

Sal##ds d'hébergeurs hein, font rien qu'à freiner les magnifiques élans (quasi poétiques) de ces demi-divinités que l'on appelle des développeurs - Sont un peu bas du front, avouons-le, ces vils marchands, ils ne savent pas la poésie de l'opérateur ternaire. :lol:

J'espère que ça remontera et qu'une solution sera trouvée... Ce que j'en dis....

[Jean le Chauve]

Ça n'a rien à voir avec une vérification de data, c'est pour améliorer la vitesse de recherche.
Soit tu passes en 5.6+ (ce que tu devras de toutes façons faire un jour), soit tu passes la table en question en MyISAM et je t'avais fait un code pour le faire automatiquement (à l'époque).

[Jean le Chauve]

Et tu n'auras aucun effet de bord.

[pierrepercee]

Salut Jean,

On s'est croisé. Ta proposition est intéressante, je crois que je vais suggérer à tous mes clients chez OVH de passer à une offre performance. Si je leur explique que ce choix intéressant a été retenu pour gagner 0.00.1% de performance sur un site moyen de 100 pages je suis bien certain qu'ils auront le sourire. Devraient même me féliciter.

Si c'était aussi simple hein !

Sinon je sais pas à quoi rime cet ultime péripétie mais la traduction de la citation de OuiK "New installs use InnoDB instead of MyISAM which allows for data integrity" c'est à priori "la nouvelle installation utilise Innodb ce qui permet l'intégrité des données" (en fait ACID qui a tout à voir avec la vérification des transactions...).
Pour les gains en performance en recherche j'avoue je sais pas...

Je me souviens parfaitement du code sql pour changer le type des tables sur l'ensemble de la base ce n'est pas le problème.
Si je me souviens bien tu avais des bugs avec une install et je t'avais signalé les problèmes possibles avec les types de table non ?

Mais si ça convient à tout le monde, ça me convient aussi, je ne suis pas contrariant

[Jean le Chauve]

New installs use InnoDB instead of MyISAM which allows for data integrity

C'est là qu'il est le bug, il manque un mot après "allows", je pense que ce doit être "searches".

MySQL supports text searching by using the LIKE statement and regular expression. However, when the text column is large and the number of rows in a table is increased, using these methods has some limitations:

Performance: MySQL has to scan the whole table to find the exact text based on a pattern in the LIKE statement or pattern in the regular expressions.
Flexible search: with the LIKE statement and regular expression search, it is difficult to have a flexible search query e.g., to find product whose description contains car but not classic.
Relevance ranking: there is no way to specify which row in the result set is more relevant.

Because of these limitations, MySQL extended a very nice feature so-called full-text search. Technically, MySQL creates an index from the words of the enabled full-text search column and performs searches on this index. MySQL uses a sophisticated algorithm to determine the rows matched against the search query.

La suite sur mysqltutorial.org

Conclusion, que Calguy ait implémenté ce type d'indexage est une très bonne chose.
Je suppose qu'il a également une opinion bien arrêtée pour préférer l'emploi d'InnoDB et je n'ai pas les compétences pour en juger.
On peut aussi supposer que la plupart des hébergeurs sérieux passeront vite à 5.6+ car il s'agit d'une évolution importante. D'ailleurs, on retrouve ce type d'erreur sur des sites propulsés par d'autres cms (WP entre autres).

[pierrepercee]

Moi non plus je ne suis pas un spécialiste des bases, à l'époque je crois bien avoir plaidé pour une solution tout Innodb et je crois me souvenir qu'on ma répondu que pour du site courant l'intégrité référentielle ce n'est pas capital mais que par contre MyIsam est beaucoup plus rapide qu'Innodb en select et en update.
Bref je serais positivement ravi de voir toutes les bases en Innodb. Mais quelques tables en Innodb et d'autres en MyIsam c'est moins rassurant.

Quant aux autres CMS, le fait qu'il rencontre des problèmes voisins pour les mêmes raisons, à mon sens cela ne constitue pas une invitation à les imiter.

Tu peux t'amuser à taper "MyISAM which allows for data integrity" sur Google et tu te rendras compte que vraisemblablement Calguy parlait bien du fait que MYisam peut poser des problèmes d'intégrité référentielle
ici par exemple et à plein d'autres endroits.
La littérature sur Myisam parle très souvent de ces problèmes d'intégrité référentielle et je pense que c'est bien de cela dont parlait CG.

Dans un certain sens cela valide le choix de CG même si on a temporairement des problèmes sur certains hébergements.


Encore une fois si je suis le seul à m'en inquiéter ce n'est pas très grave.
Sur ce j'y retourne !

[Jean le Chauve]

Ok, mais il manque quand même un bout à cette phrase :/
Donc voilà, tu as peut-être bien donné la réponse dans ton premier paragraphe. Et puis, se mélanger peut être très agréable )

[pierrepercee]

Pas faux cette histoire de mélange hein...