[Zope-dev] zope and writes

[Phillip J. Eby]

At 01:57 PM 4/15/00 -0600, mindlace wrote:
>
>There've been various comments about how the ZODB isn't particularly
>suited towards write-intensive scenarios. What I'm wondering is whether
>this shouldn't be altered to be rewrite intensive scenarios.

That's fairly accurate.


>For example, if I add an object to the ZODB, I've just added the
>object.  However, if I *change* that object, I now have two objects- as
>it is now, and as it was previously.
>
>Now, is this all inclusive?  I'm thinking of using the ZODB to store
>information like a mailing list archive.  The vast majority of the data-
>the messages themselves- would never change.  However, I'd like to have
>meta-data, like scoring on messages, that would change.

Right.  That's why it's usually said as write-intensive, since it's rare to
have a true write-only with no rewrites, because usually there's some kind
of index or metadata that will need to be rewritten even if your primary
data is mostly additive.


>If I change a property on a DTML Document, does the ZODB store a copy of
>all of the document's other properties (which haven't changed?)
>
>If so, is there a way to pack on a "per-object" basis, or would I just
>need to use some kind of non-versioning storage?

This is one of the reasons behind the database-independent SheetProviders
concept which has been partially implemented in the ZPatterns toolkit.
SheetProviders allow you to give objects property sheets which are stored
in "other" databases.  So you could store your meta-data in an SQL or other
database by giving the objects a property sheet tied to a SheetProvider
that worked against SQL.  But the interface for managing the properties
would remain the same.

To implement what you want with the ZPatterns toolkit, you would need to
subclass three things: Rack, Rackmountable, and SheetProvider.  Rack is the
base class for the container which would house your archive, while
Rackmountable is the base for things to be stored in it.  SheetProvider you
would subclass to create an object that returned a PropertySheet using SQL
(or whatever).  You would also need to create a PropertySheet class that,
when changed, would update the SQL database.  I hope to include generic
SQLSheetProviders and LDAPSheetProviders (with PropertySheet classes to
match) in later releases of ZPatterns, but for right now you have to roll
your own.