Ta vision des choses est bonne si tu pars du principe qu'avec Zope on gère des fichiers. Mais ce n'est pas le cas, avec Zope on gère des objets, pas des fichiers.
La ZODB n'est pas qu'une base de donnée ou un système de fichier. C'est, basiquement, un depôt d'objet qui offre principalement 2 services:
- Un mécanisme de persistance objet
- Un système de stockage
Le mécanisme de persistance permet de laisser le soin au système de gérer le stockage des objets. Cela évite ainsi au développeur de gérer pour chaque classe le stockage des objets (et donc, comme c'est le cas sans mécanisme de persistance de gérer à lamain le mapping objet <-> stockage physique).
Cette partie est d'ailleurs paramétrable via APE (Adaptable Persistance) qui permet de définir la façon dont on souhaite réellement stocker les objets : en tant que tel dans le dépot, sur le FS, sur le FS et dans le dépôt, dans le dépot et dans une base SQL, complètement dans une base SQL, etc. APE permet de définir complètement le mapping entre les objets et leur stockage.
Le système de stockage offre un mécanisme pour stocker physiquement le dépôt d'objet. Le mécanisme de base (FileStorage) stocke le dépôt dans un gros fichier ce qui a l'avantage d'être simple à mettre en place mais a la limite de la taille du fichier et des capacités de manipulation d'un gros fichier par l'OS.
Mais ce n'est pas grave. Il existe, en effet, de nombreux systèmes de stockage (ZODB Storage) qui permettent de stocker le dépôt de multiple façon : un fichier par objet dans une hiérarchie de répertoires (DirectoryStorage), une base Oracle (OracleStorage), une base BerkeleyDB (BSDDBStorage), distribué (sur un serveur de base Zope : ZEO), etc.
Une même instance de Zope peut d'ailleurs utiliser simultanément plusieurs stockages suivant les besoins (par exemple un DirectoryStorage pour les données et un BSDDBStorage pour les sessions).
Si l'on voit la couche ZODB comme une simple base de donnée, on peut considérer que c'est une mauvaise base, mais si l'on la considère comme un mécanisme de persistance, on constate que c'est un formidable mécanisme de persistance qui arrive au niveau de ce que l'on peut trouver dans le monde J2EE. Il ne faut pas se tromper d'utilisation. De même que si l'on utilise Zope pour simplement gérer des fichiers, je pense que ce n'est pas un bon choix. En revanche si on utilie Zope pour écrire des application web de gestion, travail collaboratif, gestion de contenu ou même traitement comptable, je pense que c'est un excellent choix.
Enfin, la partie de gestion physique (I/O) de la ZODB est écrite en C, pas en python. Donc ce qui manipule le gros fichier c'est du C :-)
[^] # Re: Première version packagée de CPS3
Posté par Eric Barroca . En réponse à la dépêche Première version packagée de CPS3. Évalué à 6.
La ZODB n'est pas qu'une base de donnée ou un système de fichier. C'est, basiquement, un depôt d'objet qui offre principalement 2 services:
- Un mécanisme de persistance objet
- Un système de stockage
Le mécanisme de persistance permet de laisser le soin au système de gérer le stockage des objets. Cela évite ainsi au développeur de gérer pour chaque classe le stockage des objets (et donc, comme c'est le cas sans mécanisme de persistance de gérer à lamain le mapping objet <-> stockage physique).
Cette partie est d'ailleurs paramétrable via APE (Adaptable Persistance) qui permet de définir la façon dont on souhaite réellement stocker les objets : en tant que tel dans le dépot, sur le FS, sur le FS et dans le dépôt, dans le dépot et dans une base SQL, complètement dans une base SQL, etc. APE permet de définir complètement le mapping entre les objets et leur stockage.
Le système de stockage offre un mécanisme pour stocker physiquement le dépôt d'objet. Le mécanisme de base (FileStorage) stocke le dépôt dans un gros fichier ce qui a l'avantage d'être simple à mettre en place mais a la limite de la taille du fichier et des capacités de manipulation d'un gros fichier par l'OS.
Mais ce n'est pas grave. Il existe, en effet, de nombreux systèmes de stockage (ZODB Storage) qui permettent de stocker le dépôt de multiple façon : un fichier par objet dans une hiérarchie de répertoires (DirectoryStorage), une base Oracle (OracleStorage), une base BerkeleyDB (BSDDBStorage), distribué (sur un serveur de base Zope : ZEO), etc.
Une même instance de Zope peut d'ailleurs utiliser simultanément plusieurs stockages suivant les besoins (par exemple un DirectoryStorage pour les données et un BSDDBStorage pour les sessions).
Si l'on voit la couche ZODB comme une simple base de donnée, on peut considérer que c'est une mauvaise base, mais si l'on la considère comme un mécanisme de persistance, on constate que c'est un formidable mécanisme de persistance qui arrive au niveau de ce que l'on peut trouver dans le monde J2EE. Il ne faut pas se tromper d'utilisation. De même que si l'on utilise Zope pour simplement gérer des fichiers, je pense que ce n'est pas un bon choix. En revanche si on utilie Zope pour écrire des application web de gestion, travail collaboratif, gestion de contenu ou même traitement comptable, je pense que c'est un excellent choix.
Enfin, la partie de gestion physique (I/O) de la ZODB est écrite en C, pas en python. Donc ce qui manipule le gros fichier c'est du C :-)
EB.