Hash: SHA1

Joachim Schmitz wrote:
> Tres Seaver schrieb:
>>> <BTrees._IOBTree.IOBTree object at 0xb562fadc>
>>> <DateIndex at created>
>>> <Products.ZCatalog.Catalog.Catalog object at 0xb12d622c>
>>> <CatalogTool at portal_catalog>
>>> <CPSDefaultSite at uniben>
>>> <Application at >
>>> {'Application': <Application at >, 'ZGlobals': <BTrees._OOBTree.OOBTree 
>>> object at 0xb2739224>}
>>> What does this tell us ?
>> That is a "real" conflict:  both transactions have inserted values into
>> the 'created' date index's '_index'  under the same key, which can't be
>> resolved.  Retrying the transaction is the only choice here.
>> Because DateIndexes convert the indexed value to an integer with
>> precision of one minute,
> really one minute or do you mean second.

Yes, really one minute.

>   a date index on 'created' is fairly likely to
>> generate such conflicts when two parties both create content at the same
>> time.
> But then I wonder how a CMF site could ever work,

You only see conflicts on this index when two people try to insert
content at the same time (i.e., they both start from the same "base"
transaction ID).

> this error shows up 
> already on my lokal system when to users add something. On our live 
> system it is killing our portal ?
> I would consider this a bug.

Perhaps the QueueCatalog product would help you:   that would allow you
to defer updates to the "conflict-prone" indexes (created, modified,
plus any {ZC,}TextIndexes) for handling by a separate batch process:


It looks as though you may need the trunk version for compatibility with
Zope >= 2.9.

- --
Tres Seaver          +1 540-429-0999          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to