On Sat, 3 Mar 2001, Chris McDonough wrote:
> Has the physical path of the object changed?  If not, the newer (2.3.0 + )


> 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.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to