Jimmie Houchin:
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
I think the RIPP model will work fine as well. It's a solution to the propertysheet/instance data source anonimity problem, but not the ZODB storage issue. Once you put things in Racks it really ceases to matter that the ZODB contains your implementation/classes, etc... because it's the instance data that is a hog. I'm going to use RIPP as well. 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.