Many thanks to Casey and Dieter for their efforts to resolve my very strange zcatalog problem Following is a summary of the problem and the solution for the archives: A dtml method was being used to update the property fields of a object located in a subfolder. The dtml method then used reindex_object to get the 'CatalogAware' zcatalog to update its indexes and metadata. This is a standard approach that we have used successfully on many applications. In this particular application there was a problem. The property fields on the object (a ZClass instance) were being updated correctly and a new entry was being created in the Catalog, but the original Catalog entry was not being removed (in an zcatalog update, a new entry is created and the old entry is deleted, you can see this by checking the rid numbers). The Catalog had two entries, with different data, pointing to the same object, which caused zope errors in subsequent catalog accesses. The problem turned out to be security/permission related. The dtml method had been written and tested through the ZMI via an https url. The dtml method was subsequently put into production and accessed via an http url. Apache is being used as the front-end and there is some url rewriting of both the https and http urls, which may have been a contributing factor. When the production system was moved to an https url, the zcatalog problem 'went away'! We don't know the exact cause of the problem, but it appears to be that access via http didn't have sufficient security/permission to allow zcatalog to delete the original entry, but it did allow zcatalog to create the new entry. As part of the debugging process we changed security settings for the subfolder, catalog and tried proxy settings for the dtml method, but none of these had any effect on the problem. It was only fixed by moving to an https url. Thanks again to all who sent ideas, Jonathan Hobbs , below a Catalog (zcatalog) was creating a new creates a new entry (a copy of
the original entry) with the new field data (property fields on the object are metadata fields in the zcatalog). The original object in the subfolder is NOT modified (ie. the property field is not changed) and the original zcatalog entry is still in the zcatalog, also not modified.
You do not ask for a ZCatalog enhancement! You face a "resolve_url" problem.
Small Business Services wrote at 2004-1-28 10:17 -0500:
How about some form of record-locking features? ... <dtml-with DNSData> <dtml-in "Catalog({'id' : dns_id})"> <dtml-with "resolve_url(getpath(data_record_id_),REQUEST)"> <dtml-call "propertysheets.GritsDNSPS.manage_changeProperties(REQUEST)"> <dtml-call reindex_object> </dtml-with resolve url> </dtml-in catalog> </dtml-with>
What I expect to happen is that the property field on the object in the DNSData subfolder is updated, then the zcatalog record is updated.
What actually happens is that the zcatalog creates a new entry (a copy of the original entry) with the new field data (property fields on the object are metadata fields in the zcatalog). The original object in the subfolder is NOT modified (ie. the property field is not changed) and the original zcatalog entry is still in the zcatalog, also not modified.
What you (almost surely) see is "virtual host dependancy" of "resolve_url" or another "virtual host dependancy" (e.g. by using "CatalogAware" instead of "CatalogPathAware").
You should avoid "resolve_url" and instead use "getObject"; you should avoid "CatalogAware" and instead use "CatalogPathAware".
-- Dieter