AdoDB vs PDO about lodel

[nahuelange]

En effet, mais ça demande un énorme travail, car c'est l'API de AdoDB qui est utilisé.
Ce qui serait encore mieux, serait de rendre agnostique les appels à base de données pour pouvoir utiliser n'importe quels moteurs de db, mais cela représente un encore plus gros travail, car toute la partie de sauvegarde/restauration de site est basé sur des dumps sql.

[charlycoste]

Cela peut représenter une grosse quantité de travail mais si c'est un objectif clairement identifié par un milestone dans le bugtracker, les contributeurs éventuels pourront travailler dessus en toute sérénité, sans peur de voir leur merge request rejeté.

L'API PDO est l'API Objet standard de PHP pour l'abstraction des bases de données et permet (via des pilotes en langage C) de rendre l'application compatible avec les SGBD suivants:

• Cubrid
• FreeTDS / Microsoft SQL Server / Sybase
• Firebird
• IBM DB2
• IBM Informix Dynamic Server
• MySQL 3.x/4.x/5.x
• Oracle Call Interface
• ODBC v3 (IBM DB2, unixODBC et win32 ODBC)
• PostgreSQL
• SQLite 3 et SQLite 2
• Microsoft SQL Server / SQL Azure
• 4D

Pour rendre les appels agnostiques, je connais le composant Database des eZComponents, une surcouche de PDO dont j'apprécie la clarté.

Une requête s'exécutant de la manière suivante:

$db = ezcDbInstance::get();

$q = $db->createSelectQuery();
$q->select( '*' )
  ->from( 'quotes' )
  ->where( $q->expr->eq( 'author', $q->bindValue( 'Robert Foster' ) ) )
  ->orderBy( 'quote' )
  ->limit( 10, 0 );

$stmt = $q->prepare();
$stmt->execute();

Le composant traduit l'objet requête en une requête SQL via un mécanisme de fabrique abstraite. Cependant, cette API n'est pas standard et le projet eZ Components est à l'abandon mais ça peut donner de bonnes idées, et c'est sous licence BSD.

[nahuelange]

Bon, après discussion dans notre équipe, nous avons décidé d'enlever PDO, car nous avons des besoins de répartition de charge sur des grappes de serveurs MySQL, AdoDB ne permettant pas ça et l'adaptation de celui-ci n'étant pas évidente, on va réécrire une couche d'abstraction qui reprend la même API que AdoDB qui est utilisée dans lodel et qui utilisera PDO.
Si tu as des remarques ou des idées, n'hésites pas à nous en faire part.

[nahuelange]

«nous avons décidé d'enlever PDO»… erreur il s'agit bien de AdoDB :)

[charlycoste]

Tout dépend comment vous souhaitez implémenter cela. La seule fois où j'ai travaillé avec un cluster de bases de données, c'était avec du PostgreSQL et l'interface était totalement transparente. Le code à écrire était le même, que l'on utilise un ou plusieurs serveurs.

Par ailleurs, une base de données doit pouvoir gérer des contraintes d'intégrité. Un cluster de base de données signifie: soit des performances plus faibles car il faut que les serveurs synchronisent leurs transactions, soit des données plus volatiles car il aura fallut désactiver la gestion des contraintes.

Si le respect des contraintes d'intégrité est secondaire et que vous avez de gros besoins côté base de données, préférez peut-être une implémentation NoSQL avec MongoDB, CouchDB, etc. qui sont conçus pour la répartition de charge (= configuration plus simple, et meilleurs performances)

Sinon, pour ma part, quand il s'agit de problèmes de charge, je privilégie une meilleur gestion de cache côté front.
Il me semble que OpenEdition est plus sollicité pour de la consultation de contenu que pour des opérations nécessitant des écritures en base de données.
S'il fallait donc rajouter des machines quelque part, j'aurais eu plutôt tendance à rajouter des serveurs de cache que des serveurs de base de données (Varnish est très bon pour ça)
Car si deux serveurs de cache ont une version différente d'une même page à un instant donné, cela reste moins grave que deux bases de données avec des tables différentes.
Et une page servie par un serveur de cache ne nécessite aucun appel à la base de données...

[nahuelange]

Je me suis mal exprimé, ou mal développé l'idée, la problématique n'est pas vraiment de la charge système, pour ça lodel s'en sort très bien avec son cache, et éventuellement avec un Varnish en façade.
Sur des infrastructures comme celle d'OpenEdition (ou d'autres plateforme) la problématique est la gestion des erreurs: pouvoir basculer sur de nouveaux serveurs de façon relativement transparente.

[charlycoste]

A ce moment là, je suggérerais (mais ce n'est que mon point de vue) de se concentrer sur l'infrastructure en elle-même (je suppose qu'un fallback est envisageable au niveau réseau afin d'obtenir une architecture n-tiers bien découpée).
Intégrer la gestion d'un cluster dans l'application ne fera que complexifier le projet et casser l'abstraction de la couche d'accès aux données en la rendant dépendante du serveur utilisé.
De plus, cela n'apporte rien aux utilisateurs ayant de petits besoins.
Si toutefois vous décidez d'intégrer un mode cluster, je vous conseille de bien étudier le code du projet eZ Publish qui a capitalisé une grande expérience à ce sujet (ainsi que beaucoup de bugs)