On Thu, Aug 6, 2009 at 9:28 AM, Gustavo Rahal <gra...@linux.vnet.ibm.com>wrote:
> Em Ter, 2009-08-04 às 06:28 -0400, Jim Fulton escreveu:
> > On Mon, Aug 3, 2009 at 9:09 PM, Gary Poster<gary.pos...@gmail.com>
> > >
> > > On Aug 3, 2009, at 3:00 PM, Gustavo Rahal wrote:
> > ...
> > > 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
> > Gustavo,
> > Note that a simpler variation on this is to assign the values
> > randomly. Assigning them sequentially from a random starting point is
> > an optimization to reduce the number of BTree nodes read and updated
> > by a particular client.
> > Jim
> Thanks for the responses. I realized that I'm mixing Zope3 with ZODB. So
> I should have asked if Zope3 offers anything in the uniqueness direction
> and I found out that apparently it does. Anyway, it was good to know how
> to deal with uniqueness in ZODB "standalone"
> pg 61 of Zope3 Web Component Architecture
> Schema field parameters
> "unique -> Specifies whether the values in a collection must be unique
> or not. Applicable to all collection fields (including sequence fields)"
> I guess that is what I wanted correct?
depends on what your looking for. if your looking for a value to be within a
collection on a single persistent object, you can utilize this, but at a
cost of write concurrency, as it creates a chokepoint for multiple writers.
for multiple persistent objects in the object database you'll need something
additional. gary's reply gives a more technical understanding of the
solutions. another simple solution is to use the unique value as the
object's key within its container.
Zope3-users mailing list