At 3:20 PM +0000 5/4/00, Jason Spisak wrote:
Jimmie Houchin: [snip] What is the primary reasoning behind the per class? Is that how the ZODB works now? I think it's transaction based. I think I understand now. It's like a row in an RDBMS. Yes, we are talking about two different animals. I think the important thing is the transparency of as Phillip said "persistance providers". A place to get you persistance, whether stored by class/object/transaction, they should all give Zope what it needs...an object with a current transaction/version state.
Actually it would be similar to a table in a RDBMS with the table being in it's own file. As per a reply from Philip, it really isn't necessary for this to be in it's own file. This doesn't really have anything to do with transactions per se. Transactions are somewhat independent of this idea and of storages. My idea had ZODB operating exactly as it currently does except with multiple files based on classes because certain objects will have different usage characteristics. That said. I like better what Philip is proposing with Racks as it fully satisfies my thoughts and provides an overall framework and philosophy for development which much more versatile and extensable. Hope this helps. Jimmie Houchin
Each class gets it's own db file. This could be similar to the current ZODB file except specific to a class. As objects are created they are appended to the db file for their class. This could be somewhat analogous to tables in an RDBMS. [snip]
Thanks.
Jimmie Houchin
All my best
Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544
Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.