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.