2013/8/19 Dsls <d...@morefnu.org> > > Je repars d'une feuille quasi blanche parce que ça vire au concours de > > bites. Ce qui n'est pas le but, d'autant que nous avons tous d'autres > choses > > à faire. > > +1 > > > De plus, dans notre cas, PDO ne suffirait pas seul à remplacer > > dbLayer/dbSchema. Il faudrait donc réécrire une fine couche de wrapper > > au-dessus de PDO. Ce qui signifierait introduire de nouveaux composants > au > > sein d'un espace de code sensible. Le changement pour le changement... > > Est-ce notre priorité ? Je ne pense pas. > > > > Ma dernière question du précédent mail était une vraie question, > puisqu'elle > > revenait à dire : > > * Listons les véritables manques et faiblesses de ces composants de CB. > > * Mesurons leur impact sur ce qui est faisable ou non avec DC. > > * Voyons ceux que nous pouvons accepter et ceux qu'il nous faut combler. > > * Et décidons alors de la suite à donner. > > A mes yeux, ce qu'il faudrait ajouter à CB : > * les prepared statements. Pas forcément pour le core (quoique, ça > rendrait certaines choses plus lisibles), mais surtout pour permettre > de blinder les plugins pour les contributeurs qui n'ont pas forcément > toutes les notions de sécurité derrière. > * La gestion des auto-increments/serial/sequences et des lastinsertid > associés. Ça me pique toujours les yeux de voir comment on insère une > nouvelle entrée dans les tables, j'ai l'impression de travailler comme > il y a 15 ans... > * Une vraie abstraction indépendante de la DB (mais là je rêve un > peu). Exemple : pgsql <8.2 ne supporte pas les insertions multiples en > une requête, mais supporte le multi-requête, mysql ne supporte pas le > multi-requêtes.
et ça doit même dépendre des versions de MySQL, non ? Il y a des approches à la iBatis (monde Java) où on travaille en SQL mais où on définit dans un fichier les requêtes SQL que l'on va utiliser pour un type de base de données. Ensuite, on n'a plus qu'à (c) demander la requête nommée pour l'exécuter de manière indépendante de la db. -- Dev mailing list - Dev@list.dotclear.org - http://ml.dotclear.org/listinfo/dev
