Committo,Ergo:sum a écrit :
il faudrait remplacer toutes les clauses touchant à des champs de type TEXT (donc CLOB sous Oracle) par l'appel à la procedure stockée CONTAINS qui utilise le moteur d'indexation (Oracle Text).
Vu ou se situe la couche d'abstraction base de donnée de SPIP, ca ne parait pas vraiment possible, sauf à faire des transformations lourde et à la volée sur les requetes.
Ou alors, il faudrait détailler encore plus l'API SQL de SPIP, peut etre meme revoir les critères des boucles, pour differencier les clauses sur des champs texte, ce qui n'est pas vraiment envisagea en 2.x
Comme ESJ a l'air d'accord avec moi pour dire qu'installer SPIP lui meme sur Oracle n'a pas d'interet, je propose une solution simple et efficace.
Oracle n'offre pas les mêmes opérateurs pour les Varchar et les *LOB,
Oracle ne permet tout simplement PAS d'utiliser les *LOB et autres LONG dans les clauses WHERE
Il faut passer par une procedure stockée => c'est plus du SQL, c'est un melange SQL / PL-SQL
alors que MySQL met tout ça dans le même panier, c'est ça le pb de fond et il apparaîtra aussi lorsque le compilateur appliquera des opérateurs Oracle incorrects sur des champs d'une base externe.
Oracle ne permettant pas de faire une clause WHERE sur ce qui est pour spip un champ de type TEXT, et les boucles correspondant à du code SQL après compilation, de facto, cela interdit l'usage de critère sur ces champs ou cela necessite la surcharge des critères (pour voir le type du champ et adapter la syntaxe en fonction, ne serait-ce que pour un =, alors que dire d'un LIKE ou d'un == ...)
C'est pour ca que je dis que c'est un probleme de conception.
Soit tu decides d'enrichir l'API SQL pour différencier les clauses sur les champs de type TEXT, et tu es obligé de modifier ca partout dans SPIP, soit tu agis in fine sur la requete générée, mais ca t'oblige alors à analyser la requete et à modifier les critères concernant ces champs.
Avec l'architecture actuelle, je ne vois pas ce que tu peux faire d'autre
En commençant par porter l'espace privé, je tombe sur le pb de manière directe, c'est beaucoup plus simple de comprendre ce qui se passe alors. On peut aussi voir cet espace privé comme un jeu de tests en vraie grandeur du fichier de portage.
Ben moi j'aurais plutot considéré l'espace public comme le jeu de test, si le but c'est d'utiliser des boucles...
Evidemment, toutes les fonctions d'accès en écriture ne sont pas utiles à la visualisation d'une base externe par des squelettes, tu n'as donc pas tort en disant que tu apportes une solution au pb d'insertion sur lequel je suis tombé.
Je n'ai parlé d'insertion à aucun moment.
Je te dis justement que ca concerne TOUTES les requetes, pour peu que la table contienne un champ de type TEXT (spip autorisant l'utilisation de critere sur tous les champs)
Mais évacuer un pb n'est pas le résoudre: tu dis que l'opérateur d'insertion n'a pas besoin d'être porté, mais c'en est qu'un parmi d'autres qui ne s'évacueront pas comme ça.
on est bien d'accord, mais encore une fois, on ne parle pas ici de bandeau, meta ou autre critère mode de la boucle document, on parle de syntaxe (non-)SQL d'oracle en général
De plus, et ce n'est pas un hasard, ce pb a révélé une utilisation de la table meta très contestable pour les raisons que Fil a exposées. Tout ça n'est donc vraiment pas inutile.
C'est jamais inutile, et effectivement, ca leve des lièvres (quoi que, ca fait longtemps qu'on sait que le stockage de gros tableaux serialisés en base, c'est pas génial, mais ca a normalement pour seul but de pouvoir regénérer le fichier de cache correspondant, c'est valable pour meta, plugins, le couteau suisse et sans doute pas mal de plugins).
Donc oui, changer la conception permettra d'eviter de se confronter au probleme pour ce qui touche aux metas... mais rien de plus.
@++
