On Aug 3, 2009, at 3:00 PM, Gustavo Rahal wrote:
> So, i'm reading zope3 web component architecture book (quite cool by
> way) and since i'm too SQL DB oriented I was wondering how to garantee
> fields uniqueness in ZODB.
> For instance, if I have a IMachine interface, I want the ip_address
> field to be unique across all machine objects.
> Is that something I have to tie in the validation routine of
> Other options?
A classic approach would be to take advantage of transactions with an
index that you maintain. Have a data structure (index-ish) that keeps
track of used ip addresses. Update the data structure in the same
transaction that creates and assigns it. When you commit the
transaction, if another concurrent transaction used that IP, one of
them gets a conflict error. Otherwise, you're good.
You need to be aware of three potential gotchas with this approach.
First, if this is going to be a lot of data, you need to make sure
that the data structure you use is divided across multiple persistent
objects so that one write does not cause the data for the entire set
to be written.
Second, if there's going to be a fair amount of concurrency, you need
to make sure that insertions in the data structure do not always want
to write to the same object--so for instance, you do *not* want to use
an approach that will make all potential concurrent IP address
creations the same.
Third, if the collection (index) you are using uses conflict
resolution, you need to understand it and make sure its behavior will
not break the transactional constraints that you want to enforce.
Practically, using the BTrees that the ZODB provides will typically
have the behavior you want for the first and third gotcha. For the
second gotcha, we typically give each connection to the ZODB its own
random starting point stored on a volatile (disposable) attribute for
the index, and each connection increments that point. Look at the
code in zope.intid, for instance: _generateId in
Zope3-users mailing list