On Mar 23, 2008, at 1:30 PM, Roché Compaan wrote:
On Sun, 2008-03-23 at 11:38 -0400, Sean Allen wrote:
Can that be wrapped in a transaction so that if something goes wrong
with customer creation, the order gets rolled back as well?
Or put higher level, do transactions only work within a single folder
or across folders?
You can modify as many objects as you like in a transaction. Have you
read the ZODB/ZEO programming guide yet?
yes but the examples are always about objects in a single folder.
wasnt sure if different folders would have any impact.
i assumed not, but you know where assumptions get you.
There is another good reason - it makes a lot more sense to
object creation to different containers in the ZODB to avoid write
I think I understand this but can you elaborate?
By 'distribute object creation to different containers' do you mean
object in own folders?
No that would lead to an unnecessary proliferation of folders and it
wouldn't actually remove conflict errors.
Conflicts errors occur when two concurrent transactions modify the
attribute. When you are putting objects in a folder you are
modifying the same attribute (unless you are using a btree). A good
application design strategy for the ZODB is to ensure that
transactions are modifying attributes on different objects. If you
putting all your orders in one folder you are increasing the chances
If you dont put all orders in a single folder, when it comes time to
search orders, how would you know where to find?
Do you sequentially search the multiple folders for a given object?
No. You index the order attributes that you want to search on and
perform a search on the indexes. Have a look at zc.index and
I think you will also benefit a lot by looking at Zope as development
platform. Have a look at the Zope3Book:
I have not as it seemed rather Zope specific.
Are there particular parts I could zero in on as being particularly
When I review the index, there isnt anything that jumps out and says,
o read me. I have read the zodb/zeo guide as well as several other
things my googling turned up plus some misc other documents
from zope.org that seemed applicable.
The big problem I have is that all the zodb stuff i have found is
either very trivial or tied up zope. Zope by this point in time,
is a highly advanced and complicated system from the outside.
Having to slog through zope specific stuff trying to pick out
zodb details is frustrating.
If I go with zodb as a backend, I would intend to help others
who come in the future by providing more zodb specific
docs that arent at all tied to zope. ( I've actually come across
many blog point that make that specific point ).
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org