> 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

> This leaves me with a different problem, though.  Sometimes when the
> 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
> > in the index to what is to be put in.  If they're the same, do nothing.
> > 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!  ;-)

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

Reply via email to