Re: [Zope3-Users] ZODB and unique values
On Thu, Aug 6, 2009 at 9:28 AM, Gustavo Rahal wrote: > Em Ter, 2009-08-04 às 06:28 -0400, Jim Fulton escreveu: > > On Mon, Aug 3, 2009 at 9:09 PM, Gary Poster > wrote: > > > > > > 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 > http://svn.zope.org/zope.intid/trunk/src/zope/intid/__init__.py?rev=100049&view=auto > > > > > > 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. cheers, kapil ___ Zope3-users mailing list Zope3-users@zope.org https://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] ZODB and unique values
Em Ter, 2009-08-04 às 06:28 -0400, Jim Fulton escreveu: > On Mon, Aug 3, 2009 at 9:09 PM, Gary Poster wrote: > > > > 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 > > http://svn.zope.org/zope.intid/trunk/src/zope/intid/__init__.py?rev=100049&view=auto > > > 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? -- Gustavo Matheus Rahal IBM Linux Technology Center ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] ZODB and unique values
On Mon, Aug 3, 2009 at 9:09 PM, Gary Poster wrote: > > 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 > http://svn.zope.org/zope.intid/trunk/src/zope/intid/__init__.py?rev=100049&view=auto 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 -- Jim Fulton ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] ZODB and unique values
On Aug 3, 2009, at 3:00 PM, Gustavo Rahal wrote: > So, i'm reading zope3 web component architecture book (quite cool by > the > 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 > ip_address? > 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 http://svn.zope.org/zope.intid/trunk/src/zope/intid/__init__.py?rev=100049&view=auto . Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
