[CPS-devel] Re: getFolderContents: serious performance problem

[Yves Bastide]

> On Oct 24, 2006, at 5:39 PM, Benoit Delbosc wrote:
> 
>> Hi
>>
>> Yves Bastide a écrit :

[...]

>>> * How to systematically use getCatalogFolderContents

>> Using the ZMI add a boolean property to the portal named 
>> 'use_catalog_for_folder_contents' with a True value.

Thanks, I didn't grok 'use_catalog_for_folder_contents'

>>> * Why it's not the case already (I've had incomplete indexes, but 
>>> assume it's
>>> my fault)
>> It is a bit slower if you have only few items in a folder.

Ok

>>> * Bonus question: can one sort on several indexes -- i.e. some of my 
>>> documents
>>> have a specific field which should be used as a default sort key; how 
>>> to get
>>> also documents of other types?
>> I think you need to replace the default sort on position_in_container 
>> with 2 sort keys: your new index first then position_in_container.

Hmm, AFAICS sort_on designates one index only ...


Georges Racinet wrote:

> If you want to go further, check also CPSDashboards, a component that's 
> basically meant for this (at the expense of more configuration, it's not 
> a drop-in replacement).
> 
> It'd be applicable if
>     - you want to control according to portal_type of folder (typically 
> you'd have BTree folders to hold lots of docs, and you'd need a new 
> portal_type anyway for that)
>     - you don't need the "move up" etc buttons (didn't make them yet, 
> but you can specify an action category to get buttons)
>     - you want to fully customize the columns, etc.

Yep, using CPSDashboards is our plan for the next iteration.

> CPSCourrier's Mailbox document type can be used as a fully working 
> example/starting point.
> 
> It's also worth noting that for really big sites (> 2.10^5 documents), 
> switching to CPSLuceneCatalog is just a matter of changing a widget's 
> meta_type within CPSDashboards (basically because it was designed with 
> Lucene in sight ).

Noted.


Thanks to both of you!

yves