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 to the database layer. Catalogs would be updated automatically (in a lazy fashion to avoid performance penalties). There would potentially be a large number of catalogs, though, so the number of conflicts would increase significantly.
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.
Sounds cool. At one time Ty and I thought we might do something like this by adding to a linked list of "pending updates" which the catalog would use to alter its search results, until the list got "too long", at which point it would post the actual updates. 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 probably implement it as a simple sequence object with the conflict resolution method implemented. But then there'd be the question of how to resolve conflicts if more than one thread or ZEO client decided to apply the queued changes... a 100 conflicts vs 1 situation. Ugh. Anyway, I'd be really interested in seeing "a solution for all the issues in conflict resolution". Will it help with arguments, too? How about world peace? ;)