TUTORIEL OUTILS 
Zope : présentation de ZODB
Survol des principales caractèristiques du gestionnaire d'objets du serveur d'application développé en Python. (05/04/2004)

 

Nous avons déjà vu certains des aspects clefs de Zope avec nos articles "Présentation de Zope", "Premiers pas avec Zope" et "Aborder les langages DTML et ZPT". Ici, nous allons voir un des points les plus intéressants du développement Zope : son système de gestion d'objets persistants ZODB (pour Zope Object DataBase).

"Système de gestion d'objets persistants" peut sembler intriguant au premier abord, et nous allons donc commencer par décrire ce système, et son intérêt.

Objets persistants ?
La persistance objet a déjà fait l'objet d'un article à part : cela consiste simplement à sauver les objets indépendamment de l'application, afin de pouvoir les réutiliser au sein d'une autre application ou lors d'une autre session utilisateur.
ZODB est ainsi une base de données pour sauver les objets créés par Zope, et plus généralement par le langage Python (sur lequel Zope est bâtit).

Les objets peuvent donc y être créés et stockés au sein de cette "base de données" spécifique, qui prend en charge leur gestion, leur modification, ainsi que leur présence ou non au sein d'un cache.
Il s'agit donc d'un système de gestion de bases de données orienté-Objet (SGBDOO), avec tout ce que cela comporte de possibilités apportées par l'utilisation de la programmation Objet : classes, héritage, polymorphisme, encapsulation, extensibilité...

Ce système offre plusieurs avantage non-négligeables, dont les plus intéressants sont la transaction et l'historisation des données.
La transaction est un outil courant des SGBD utilisant SQL, donc rien de véritablement nouveau en soi. Une transaction est un ensemble de requêtes envoyé complètement, ou annulé. Cela permet de garantir que la base ne sera modifiée que si l'ensemble des requêtes sont bien exécutées. Dans le cas contraire, la base reviendra à son état inital.
L'historisation des données est déjà beaucoup plus novatrice : tout objet sera sauvé sous forme de copie avant d'être modifié. Au fil des requêtes, la taille de la base peut donc facilement croître, mais l'avantage est de pouvoir à n'importe quel moment revenir à une "version" antérieure de l'objet, à la manière d'une page Wiki.

Inconvénient, le temps d'écriture se voit lui aussi augmenté, étant donné qu'il faut recopier l'objet avant de le modifier. Pour palier à cela, la modification est faite en premier au sein du cache, et la modification physique se fait en mode asynchrone, justement pour ne pas ralentir de possibles autres requêtes.

Il est donc recommandé de n'utiliser ZODB qu'au sein d'applications ne faisant pas ou peu de modification/création dans la base, et privilégiant la lecture : un site dynamique classique sera une application parfaite, tandis qu'une application communautaire (un forum, par exemple) risque de souffrir de ce ralentissement, pour peu que ses créateurs ne sachent pas optimiser les accès. Cela n'est cependant pas rédhibitoire, le site communautaire Zopéra étant bâtit sur Zope. Zope peut bien entendu faire appel à un SGBD externe en cas de besoin : le choix est ici vaste...
Hormis cela, ZODB est le compagnon idéal des développement Zope dynamiques, en particulier ceux nécessitant un indexage "full text" solide (en combinant ZODB et ZCatalog), ou si les objets peuvent obtenir des tailles considérables (plusieurs Go).

Nous en aborderons l'utilisation dans un prochain article.
 
Xavier Borderie, JDN Développeurs
 
Accueil | Haut de page