Ressources Spip-Agora Clever Age

Le Principe général

L’abstraction de bases de données repose principalement sur l’utilisation de la norme SQL 92, définissant les standards en matière de base de données relationnelles. Idéalement, toute base de données vérifiant cette norme doit pouvoir être utilisée avec AGORA. Dans la pratique cette vérité n’en est pas une, puisque la plupart des bases de données commerciales ou libres n’implémentent qu’un sous ensemble de cette norme. Le principe général de cette couche d’abstraction est donc d’utiliser un composant central générique, vérifiant parfaitement la norme SQL 92. L’utilisation d’une base de données ne vérifiant pas un sous ensemble convenable de la norme nécessaire au fonctionnement d’AGORA nécessite donc l’utilisation d’un driver spécifique. Dès qu’un composant d’AGORA nécessite une action sur une source de données, il délègue cette tâche à la couche d’abstraction. Il s’agit donc d’un composant fondamental du framework, étant donné qu’il a la lourde responsabilité d’assurer l’ensemble des échanges de données entre le cœur applicatif d’AGORA et les différentes sources de données qu’AGORA est susceptible d’utiliser.

Cette couche d’abstraction se décompose elle-même en deux parties :
 Abstraction technique de base de données
 Abstraction métier

Abstraction technique

L’abstraction technique a pour but de permettre la connexion de l’application à n’importe quelle base de données, en utilisant une API standardisée. Elle permet donc un premier niveau d’abstraction. Cependant, cette couche seule ne suffit pas, puisqu’elle ne gère que les échanges d’informations entre le tiers données et le tiers applicatif. Elle ne permet pas en effet de transformer des requêtes SQL en requêtes compréhensibles par n’importe quelle base de données. Par exemple, une requête utilisant des fonctionnalités spécifiques MySQL ne sauraient être traduites par cette couche pour fonctionner sur n’importe quelle autre base. C’est pour cela qu’au dessus de cette couche purement technique, se trouve une couche métier, dont le rôle est principalement de standardiser les requêtes SQL, en les abstrayant derrière une API unifiée. La solution logicielle employée pour cette couche d’abstraction technique est PEAR ::DB, qui présente l’avantage de fonctionner avec un très grand nombre de bases de données différentes, et de limiter pour certains cas précis l’utilisation de commandes SQL spécifiques.

Abstraction métier

La couche d’abstraction métier est la couche appelée depuis le cœur applicatif d’AGORA lorsqu’il est nécessaire d’effectuer une requête sur la base de données utilisée. On y retrouve ainsi une modélisation de tous les objets métiers utilisés par AGORA, parmi lesquels on peut citer les articles, brèves, rubriques, auteurs, etc. C’est au sein de cette couche que la notion de « driver » fait sens. En effet, c’est dans cette couche qu’est regroupé l’ensemble des requêtes SQL. Donc, lorsqu’une requête standard n’est pas supportée par une base de données, il s’agit de redéfinir une requête qui, elle, fonctionne correctement dans ce contexte. L’utilisation d’une méthodologie objet dans la réalisation de cette couche permet de faciliter l’écriture de ces drivers. En effet, les mécanismes d’héritage et de polymorphisme permettent à l’auteur d’un driver de n’avoir à écrire uniquement les quelques méthodes contenant des requêtes non supportées.

Les types de données

Pour avoir des requêtes respectant la norme SQL 92, il a été nécessaire d’adapter les types de données.

| MySql | SQL Server | Oracle | PgSql | | bigint | int| smallint | bigint | | int | number | varchar | varchar | | Blob | longblob |text | blob | | Double | float | float | ? |

(à refaire)

La gestion des dates contrairement à SPIP qui utilise le type date de MySql, AGORA utilise le format de date ISO (« 0000-00-00 00:00:00 ») soit une chaîne de 19 caractères. Pour la manipulation des dates, nous utilisons la classe PEAR ::Date.