"resolve_url" problem (was: Re: [Zope] Re: ZCatalog enhancement wishes (and a zcatalog question))

[Small Business Services]

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