"R. David Murray" wrote:
On Fri, 24 Mar 2000, Michel Pelletier wrote:
it, therefore, I cannot fix it. The only thing I can tell you is that it has to do with ZClasses that catalog themselves and that it happens rarely and that updating your catalog allways fixes it. I suspect it has to do with poorly engineered ZClasses.
What would constitute a poorly engineered ZClass?
It's just a suspicion, and as I noted in my previous mail I cant tell you constitutes a poorly engineered ZClass because I can't reproduce the bug. By 'poorly engineered' I mean both the possibility that the bug is manifest of the user createing the ZClass, _or_ that the ZClass implementation is broken. I did not mean to point fingers.
I've seen this problem with a ZClass that is descended from just CatalogAware, has a few properties, and for which I've rewritten the Add and Edit methods to call reindex_object.
Can you reproduce it deterministicly?
I'm not sure how I could engineer this simple class better, but I don't really understand why I have to rewrite the Add and Edit methods to call reindex_object,
Because when you change an object, you must inform the catalog that the object has change so it can update its indexes.
so it could well be that there are improvements that could be made.
In my case, I did not even do an update catalog. After adding a few additional objects, the error message went away on its own.
This is because one of your new objects filled in the missing hole, it may have made the problem go away, but it didn't fix it.
(I didn't do a catalog update, because if I do that the meta data for the id field gets completely screwed up, so I stay well away from catalog update).
This has never happened to me, can you reproduce this deterministicly also?
I am running under SiteAccess, and I have a sneaking suspicion my problems orignate there. I'll be moving the database to a dedicated server soon and will remove SiteAccess. If I see the error again at that point I'll let you know.
Please do. Thanks. -Michel