|
| |
| 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.
|
|
|
|
