Incompatibilé forte: Oracle ayant {{{mode}}} comme mot-clé réservé, il ne peut être utilisé dans un champ de table.
Tu veux dire qu'il n'accepte même pas `mode` ?
En conséquence, renommage sous le nom {{{genre}}} du champ {{{mode}}} de la table {{{spip_documents}}}, avec répercussion sur les squelettes et les scripts utilisant cette table. La
Ce commit se discute, et aurait dû se discuter avant : comme tu sais,
on essaie depuis deux ans d'améliorer la question des documents, et le
point d'achoppement le plus fort est celui de la compatibilité
ascendante du champ "mode". Alors, tout faire valser d'un coup de pied
pour assurer la compatibilité avec des bases de données pas libres, je
m'interroge...
Incompatibilé forte: Oracle ayant {{{mode}}} comme mot-clé réservé, il ne peut être utilisé dans un champ de table.
Tu veux dire qu'il n'accepte même pas `mode` ?
non.
En conséquence, renommage sous le nom {{{genre}}} du champ {{{mode}}} de la table {{{spip_documents}}}, avec répercussion sur les squelettes et les scripts utilisant cette table. La
Ce commit se discute, et aurait dû se discuter avant : comme tu sais,
on essaie depuis deux ans d'améliorer la question des documents, et le
point d'achoppement le plus fort est celui de la compatibilité
ascendante du champ "mode". Alors, tout faire valser d'un coup de pied
pour assurer la compatibilité avec des bases de données pas libres, je
m'interroge...
Oui enfin, maintenant qu'Oracle est propriétaire de MySQL, qui n'a d'ailleurs jamais été sous licence GNU,
pas plus que PHP d'ailleurs, je trouve que cet argument ne serait recevable que si on utilisait exclusivement C et PostGres, ce qui ne me déplairait pas complètement mais c'est une autre histoire.
Par ailleurs, j'avais plutôt cru comprendre que j'étais loin d'être le seul à trouver incompréhensible ce champ (si j'ai bien compris issu d'un compromis mal fichu entre Arnaud et Antoine), et qu'il faudrait de toutes façons reconcevoir ce truc là. De ce point de vue, 14588 a la vertu de pointer tous les endroits où il est utilisé effectivement (car "grep mode *" c'est pas un cadeau). J'ai gardé la sémantique, il y a un sed à faire dans les squelettes, et combien de lignes de code PHP sur la zone qui attaque directement cette table ? On ne fait pas d'omelettes sans casser des oeufs, il n'y a pas de miracle (mais un oracle, si).
Mais puisqu'il faut annoncer la suite des contrariétés, j'ai gardé le plus beau pour la fin: "date" est un mot réservé.
et qu'il faudrait de toutes façons reconcevoir ce truc là.
Oui c'est la reconception façon bulldozer : je casse tout, à vous de réparer.
On ne fait pas d'omelettes sans casser des oeufs,
il n'y a pas de miracle (mais un oracle, si).
Moi ça ne m'intéresse pas de passer mon temps à courir après tes
décisions de provoquer des incompatibilités. Dans ces conditions, on
peut abandonner le développement soi-disant "collaboratif".
Mais puisqu'il faut annoncer la suite des contrariétés, j'ai gardé le plus
beau pour la fin: "date" est un mot réservé.
tu aurais très bien pu trouver un mécanisme d'exception pour Oracle.
Pareil.
Je ne vois aucun intérêt pour SPIP à supporter Oracle si c'est pour casser plein de code et de squelettes.
Le jeu n'en vaut vraiment pas la chandelle, et la moindre des choses et de discuter du sujet avant de lancer ce type de chantier.
Je conçois que la difficulté avait pu ne pas apparaître avant, mais là c'en est une qui est rédhibitoire.
Je demande à ce qu'on revienne en arrière sur 14558, et qu'on règle d'abord la refonte des documents avec cette obstacle en tête pour le contourner si possible.
Mais entre les deux (la compatibilité avec l'existant et le support d'Oracle), je n'ai aucun doute pour choisir de privilégier la compatibilité tant que les dégats sont aussi importants.
Je viens de passer un bon moment à chercher une solution alternative, j'ai fini par trouver une page Web improbable où on dit avec des pincettes que mettre le nom entre guillemets forcera la création de la table avec ça, mais que ça empêchera d'écrire des Triggers sur ces tables. Dans l'immédiat SPIP peut s'en satisfaire, il faut que je teste soigneusement voir si c'est vrai, et programmer un Revert propre ce qui n'est pas immédiat dès qu'on change le numéro de base.
Si oui, on devrait éviter l'incompatiblité introduite pour le champ "mode" et celle prévue pour le champ "date", donc tout le monde sera content. Cela dit, entre intéresser la communauté Oracle à SPIP (qui ne compte pas que des commerciaux), et conserver un champ qui a toujours été obscur à tout le monde, pour moi le choix était clair.
