On Fri, 23 Jan 2004 18:12:47 -0500 casey@zope.com wrote:
4. Investigate ZCatalogs thoroughly to make sure they meet your needs. We are about to jump ship in favor of a relational database, simply because ZCatalogs are not as well suited to our purposes.
I'd be interested to know what the specific reasons are. I have plans about improving ZCatalog in various ways, and it's always interesting >to here other outside opinions and use cases that can be used to inform future improvements.
-Casey
Please consider adding the ability to sort catalog query results on more than one index. - Sam Brauer
Sam Brauer wrote:
I'd be interested to know what the specific reasons are. I have plans about improving ZCatalog in various ways, and it's always interesting >to here other outside opinions and use cases that can be used to inform future improvements.
-Casey
Please consider adding the ability to sort catalog query results on more than one index.
Yep, that's another big one that I'd like too... cheers, Chris
Hi Chris. Chris Withers schrieb:
Sam Brauer wrote:
I'd be interested to know what the specific reasons are. I have plans about improving ZCatalog in various ways, and it's always interesting >to here other outside opinions and use cases that can be used to inform future improvements.
-Casey
Please consider adding the ability to sort catalog query results on more than one index.
Yep, that's another big one that I'd like too...
*wrapping a nice sequence.sort() into gift paper and handing it to ChrisW* ;D Tino
--On Mittwoch, 28. Januar 2004 8:50 Uhr +0100 Tino Wildenhain <tino@wildenhain.de> wrote:
Yep, that's another big one that I'd like too...
*wrapping a nice sequence.sort() into gift paper and handing it to ChrisW* ;D
I am pretty sure chrisw wants that ZCatalog can query multiple indexes and e.g. sort the result by the scores from ZCTextIndex or TextIndexNG instance. -aj
Andreas Jung wrote:
--On Mittwoch, 28. Januar 2004 8:50 Uhr +0100 Tino Wildenhain <tino@wildenhain.de> wrote:
Yep, that's another big one that I'd like too...
*wrapping a nice sequence.sort() into gift paper and handing it to ChrisW* ;D
I am pretty sure chrisw wants that ZCatalog can query multiple indexes and e.g. sort the result by the scores from ZCTextIndex or TextIndexNG instance.
-aj
Just to clarify what I was asking for... I would like to be able to specify a secondary (and maybe even a tertiary) index for sorting results. For example, I may want to do a primary sort on 'review_state' with a secondary sort on 'modified' (in descending order). Currently, this isn't possible; you can only specify a single index for sorting. - Sam
How about some form of record-locking features? I am having a real headache with the following scenario: Person A retrieves a record from the zcatalog. Person B retrieves the same record from the zcatalog. Person A modifies (via an html form) a field from the record, then the submits the form to a dtml method which has the following update code: <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. I now have one object in the subfolder and two entries in the zcatalog. Both have the same id (which causes a zope propertysheet error the next time I try to access the zcatalog record). I think I am missing something fundamental as to how zcatalog operates. Anyone have any ideas? Thanks, Jonathan
On Wed, 28 Jan 2004 10:17:54 -0500 "Small Business Services" <toolkit@magma.ca> wrote: [..]
I now have one object in the subfolder and two entries in the zcatalog. Both have the same id (which causes a zope propertysheet error the next time I try to access the zcatalog record).
I think I am missing something fundamental as to how zcatalog operates. Anyone have any ideas?
This is a bug in your application. The catalog identifies objects by their physical path (via the getPhysicalPath method). Somehow this method is returning two different values for the same object at different times. This is possible if the object is mounted in two locations in the folder tree or some trusted code changed the aquisition wrappers and rewrapped the object in a different place. You may need to set a trace in the reindex method (or earlier) so you can step through and determine why the paths come up different. -Casey
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
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
Small Business Services wrote at 2004-1-30 10:34 -0500:
... same object cataloged twice ... The Catalog had two entries, with different data, pointing to the same object, which caused zope errors in subsequent catalog accesses.
This is almost surely a "CatalogAware" problem. Check the "path" (using the "getPath" method) of your two catalog entries. I predict, that you will see two different paths -- paths corresponding to two different virtual host views of your site. I adviced previously in the mailing list (--> archives) to redefine the class "CatalogAware" in terms of "CatalogPathAware". We no longer need "CatalogAware", it makes only problems... -- Dieter
Tino Wildenhain wrote at 2004-1-28 08:50 +0100:
...
Please consider adding the ability to sort catalog query results on more than one index.
Yep, that's another big one that I'd like too...
*wrapping a nice sequence.sort() into gift paper and handing it to ChrisW* ;D
Sorting via index (as does "ZCatalog.searchResults") is (sometimes) far more efficient than "sequence.sort": In one of our sites, rendering the homepage spend about 50 % of the time in "sequence.sort". Switching to sorting via index reduced the amount of time spent for sorting to about 15 %. -- Dieter
participants (7)
-
Andreas Jung -
Casey Duncan -
Chris Withers -
Dieter Maurer -
Sam Brauer -
Small Business Services -
Tino Wildenhain