[Zope] Local FS

[Kevin Dangoor]

Hi, Jason

    I agree that RIPP, and the ability to use ZClasses as Pluggable Brains
for SQL Methods, will make a big difference in making underlying storage
transparent. I'm trying to incorporate RIPP into my thought patterns as I
design new apps so that I can take advantage of multiple backend stores for
things.

    My plan for this is that I would store things that do not require
frequent writing in the ZODB. I think the ZODB is very easy to work with and
pretty fast. For things that do need frequent writing, I would give those
objects a separate propertysheet for those attributes and store them in an
RDBMS. I think this would be a really clean, maintainable and scalable
model. The nice thing about this also is you could always start with a full
ZODB implementation of those attributes and then migrate to RDBMS later on.
Would I be able to implement this today? Nope, I don't have enough ZPatterns
and propertysheets Zen yet. But, I think it looks like a great way to go.

    BTW, when I say "frequent writing" above, I should really say "frequent
updating". I think a discussion area would be just fine to store in the
ZODB, because objects keep getting added, not updated. On the other hand,
keeping track of banner ad views should be done in some other data storage
area (RDBMS, file system).

Kevin

----- Original Message -----
From: "Jason Spisak" <444@hiretechs.com>
To: "Jonothan Farr" <jfarr@real.com>
Cc: <zope@zope.org>
Sent: Tuesday, May 02, 2000 1:26 PM
Subject: [Zope] Local FS


> How far away from being an alternative form of storage for Zope is
LocalFS?
>  I'm talking ZClass instances mostly.  A robust data storage facility for
> Zope objects in files rather than a sigle large file.  With the RIPP
> (ZPattern and the like) the backend is going to cease to make a difference
> to propertysheets, and having the local filesystem (XFS/ReiserFS) for
write
> intensive stuff is a must have for Zope.