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.