Cool. Now, in the examples I've seen for interfacing ZCatalog and ZPatterns, the 'object updated' code does an unindex of the object and then an index of the object. I copied that pattern for my "the tables have been updated, reindex everything" code. So what I should do instead is just do an index of the objects?
Yup. Don't call uncatalog_object on the object before calling catalog_object.
This leaves me with a different problem, though. Sometimes when the tables are updated objects dissapear (ie: were deleted from the external database). I have to figure out how to delete those from the catalog. A pain, but it shouldn't be too hard.
This is a problem that ZCatalog doesn't address anyway (unless you're using "CatalogAware", blech).
Note that the algoritm is simple - for each index, compare the what exists in the index to what is to be put in. If they're the same, do nothing. If they're different, reindex. I wasn't able to understand completely from your description whether the object method your're attempting to index via a TextIndex actually returns different data or not when you recatalog it. Does it?
Yeah, it should be returning exactly the same data. I can stand the update hit when the data actually changes (even though the change will typically be only one or two words out of hundreds).
We're working on integrating new BTree data structures into the indexes which will make the time/space hit very low when updating documents in which nothing has changed. I have no hard numbers, however, for the old or the new stuff.
There's a huge possibility that the merge stuff isn't working completely because until now there have been no deterministic tests.
Well, I don't know yet, since I was doing an unindex/reindex cycle.
Well, give it a shot and tell me what happens! ;-)