"Phillip J. Eby" wrote:
That is, in ZPatterns one can specify triggers such as:
WHEN OBJECT DELETED, CHANGED CALL someCatalog.manage_uncatalog(self.absolute_url(1)) WHEN OBJECT ADDED, CHANGED CALL someCatalog.manage_catalog(self,self.absolute_url(1))
After I read this again I realized what you were saying. This capability of ZPatterns is very brittle, don't you think? If the catalog is updated manually before the special ZPatterns object is added to the queue, the behavior is undefined AFAIK--either the later changes to the catalog will be ignored, will cause a conflict, or some objects will be written twice in the same transaction. However, if we could specify transaction commit priorities, and the ZPatterns update came first, auto-indexing came second, and everything else followed, I think it would work. Or perhaps ZPatterns should be able to register things that occur *before* the two-phase commit protocol. Shane