On Sat, 3 Mar 2001, Chris McDonough wrote:
Has the physical path of the object changed? If not, the newer (2.3.0 + )
Nope.
catalog stuff should be smart enough to figure out whether anything inside the object has changed during catalog_object. If nothing has changed, none of the indexes or metadata columns should be updated. We're scrambling right now to write tests for this kind of thing. :-(
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? 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.
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).
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. --RDM