Base Storage architecture

Devilstick targets to support various storages. At the time of writing this page only ZODB is implemented. But our plans are SQL, LDAP, Filesystem and more.

Architecture

Data-Access-Objects

Devilsticks architecture is highly based on storage visions. The basic architectural idea is to have a Data Access Object (see http://en.wikipedia.org/wiki/Data_Access_Object) pattern (short: DAO) for Zope. Devilstick DAO's are abstracting the storage implementation for data.

Devilstick takes into account tree-like structures like we have in Zope, Filesystem or LDAP. You can see a SQL-table as a flat tree, but you can also build tree like structures in SQL inside one table or using several tables. The story of the core starts with three types of DOA's - everything else is build around them:

root-containers: called Cages,
nodes: called Molecules,
leafes: called Atoms.

What it is not: Cages are not Site-Roots, Molecules are not Plone-Folders and Atoms are not Content-Types.

What it is: Cages are sematic and storage bound units inside a micro-structure. A Cage is also the entry point to a different storage. In Plone-Words: A content-type consists of one or usally more Cages.

Cages

Cages are the root of a storage tree. Per Cage theres usally one storage possible, even if a developer can break this paradigm for rare use-cases.

A cage can be attached to every Devilstick-enabled object.

Molecules

A Molecule is a node in a tree or in other words a container for other containers for other Molecules or Atoms.

Take a Molecule as a thing defining the structure. It has like the atom a cardinality and knows if it is implict or explict addable.

Atoms

The smallest unit containing usally one or sometimes more fields. An atom is directly implementing a zope-schema. The schema attributes are defining the data on the atom. This is also the smallest sematic unit. I.e. an Atom for a string has one schema attribute, but an Atom for a file has three, for the file itself, file-name and mime-type.

Data Models

The data-structure of a Cage is defined by its model. A model is also a tree, defining which storage is used, the allowed elements per cage or molecule, its cardinality, which atom-implementation to use, etc.

A data-model is extensible by pluggable namespaces (delegated to named adapters), so it can get rich on information outside of the scope of the DAO's (like widgets used), but the DAO-structure is the primary information.

Data models are usally just information about the configuration of the Cage. This way its possible to modify the models on run-time.

Access from the outside

If a developer is just using pre-defined, he does not need to know much about DOA's. Theres a common simple API for tasks like add, modify, read or delete. Fine-granular events are helping here to add behaviour before or after such a task perform. One also never need to think about DAO's implemenation in this case, since every DAO has an identifier and structures are projected as dotted paths accessible using a simple mapping.

Writing own Atoms/ Storages

For ZODB its simple to add new atoms. You just need to subclass a base class and tell it which zope-schema to use. If it comes to other storages, you need to have knowledge more about the storage used and also have to know internals of the DAO's. Anyway, its not difficult and ant this point you have a flexible abstraction layer built upon simple operations like, read, insert, update and delete.

Personal tools