At 04:58 PM 6/8/01 -0400, Shane Hathaway wrote:
On Thursday 07 June 2001 21:28, Phillip J. Eby wrote:
Upon being told to perform a transaction or subtransaction commit,
the transaction would notify all the ruleAgents, and then all the
indexingAgents. Objects could still subscribe to either
On Thu, 31 May 2001 10:36:55 -0400 (EDT), Shane Hathaway
[EMAIL PROTECTED] wrote:
On Thu, 31 May 2001, Toby Dickenson wrote:
On Thu, 31 May 2001 10:03:31 -0400 (EDT), Shane Hathaway
[EMAIL PROTECTED] wrote:
Right now ZCatalog randomly generates ConflictErrors even if there are no
conflicts
My last post didnt make much sense. This time ill include all the
words in my sentence
Large catalog
updates (where every object is reindexed) also generate a lot of
conflicts.
Is that last bit true? I thought 'Update Catalog' created *new*
indexes. There might be a conflict on the root
On Thursday 07 June 2001 07:43, Toby Dickenson wrote:
Large catalog
updates (where every object is reindexed) also generate a lot of
conflicts.
Is that last bit true? I thought 'Update Catalog' created *new*
indexes. There might be a conflict on the root catalog object, but
not on the
Shane Hathaway wrote:
But I think I have a solution for all of the issues in conflict
resolution. If you, or anyone else, is also interested in this, please
show support (if only by saying please do this!) :-) I can't work on
it unless I have a reason to.
Please do this! :-)
I'm
On Thu, 7 Jun 2001, Shane Hathaway wrote:
It really doesn't matter how many conflicts there are. Within a
single transaction, 1 conflict is as bad as 100.
Why?
But I think I have a solution for all of the issues in conflict
resolution.
Whee!
If you, or anyone else, is also
Me too! Me too!
John
On Thursday 07 June 2001 08:49, Chris Withers wrote:
Shane Hathaway wrote:
But I think I have a solution for all of the issues in conflict
resolution. If you, or anyone else, is also interested in this, please
show support (if only by saying please do this!) :-) I
--On Thursday, June 07, 2001 09:34:54 AM -0400 Shane Hathaway
[EMAIL PROTECTED] wrote:
But I think I have a solution for all of the issues in conflict
resolution. If you, or anyone else, is also interested in this, please
show support (if only by saying please do this!) :-) I can't work
On Thursday 07 June 2001 11:51, Erik Enge wrote:
On Thu, 7 Jun 2001, Shane Hathaway wrote:
It really doesn't matter how many conflicts there are. Within a
single transaction, 1 conflict is as bad as 100.
Why?
Because in Zope it means the whole request is processed again (which
can lead
On Thursday 07 June 2001 12:17, Phillip J. Eby wrote:
At 09:34 AM 6/7/01 -0400, Shane Hathaway wrote:
One thing I didn't make clear in the proposal is that I'm interested
in repurposing ZCatalog as a general ZODB indexing mechanism and
essentially moving it down from the application layer
At 02:07 PM 6/7/01 -0400, Shane Hathaway wrote:
On Thursday 07 June 2001 12:17, Phillip J. Eby wrote:
The
only catch was that this would still produce conflicts at the head
end of the linked list. :( Of course, that was in the days before
ZODB conflict resolution. Nowadays, you could
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
On Thu, 7 Jun 2001, Phillip J. Eby wrote:
I was thinking that certain types of objects would be committed by the
transaction manager before all others. In this case, the catalog (or a
special object in the catalog) would be committed first. It would
resolve all conflicts in the contained
At 07:07 PM 6/7/01 -0400, Shane Hathaway wrote:
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
On Wed, 30 May 2001, Shane Hathaway wrote:
I have written a proposal.
So, if I understand correctly, when this is implemented, will the ZCatalog
always resolve conflicts and never raise ConflictErrors? If there are no
ConflictErrors in the main object system?
I think I'm missing the point
On Thu, 31 May 2001 10:03:31 -0400 (EDT), Shane Hathaway
[EMAIL PROTECTED] wrote:
On Thu, 31 May 2001, Erik Enge wrote:
On Wed, 30 May 2001, Shane Hathaway wrote:
I have written a proposal.
So, if I understand correctly, when this is implemented, will the ZCatalog
always resolve
On Thu, 31 May 2001, Toby Dickenson wrote:
On Thu, 31 May 2001 10:03:31 -0400 (EDT), Shane Hathaway
[EMAIL PROTECTED] wrote:
Right now ZCatalog randomly generates ConflictErrors even if there are no
conflicts in the data being indexed. It's quite rare, however, and
there's machinery that
On Thu, 31 May 2001, Shane Hathaway wrote:
How did you miss the point? That's exactly the point! :-)
Oh :)
Right now ZCatalog randomly generates ConflictErrors even if there are
no conflicts in the data being indexed.
This is why I think I've missed a/the point: wouldn't it be better to
On Thu, 31 May 2001, Erik Enge wrote:
On Thu, 31 May 2001, Shane Hathaway wrote:
How did you miss the point? That's exactly the point! :-)
Oh :)
Right now ZCatalog randomly generates ConflictErrors even if there are
no conflicts in the data being indexed.
This is why I think I've
I have written a proposal.
http://dev.zope.org/Wikis/DevSite/Proposals/ArmoredCatalog
Could it be that we're involved in yet another Battle of Fredericksburg
and we're trying to save innocent ZCatalogs from a ZODB conflict?
Nawww... ;-)
Shane
___
20 matches
Mail list logo
