Sorting a list of fetched nodes by number of related objects

Next topic

Author	Message
Felix Laate	Wednesday 14 May 2008 4:23:15 pm Hi all, let's say we have a list of fetched nodes of a certain class that has an objectrelationlist attribute. Now I would like to sort this list by the number of objects related in this attribute. Anyone knows how? Felix Publlic Relations Manager Greater Stavanger www.greaterstavanger.com
Piotrek Karaś	Wednesday 14 May 2008 10:46:56 pm Hi Felix, I would probably extend the class whose elements are to be sorted with en ezinteger type attribute, then create a cronjob that would periodically analyse the amount (or anything else) of relations and update the value and sorting field accordingly, which would then make it possible to quite efficiently apply sorting at the fetch attribute level, without loosing the ability to still apply other filters and parameters etc. I am thinking of direct current version modifications in the ezcontentobject_attribute table, so there might be risks here, and also it would have to be adjusted to the amount of classes to analyse. Also, the caching problem will be there to solve - is that list cache-blocked, or maybe we're talking about a browse list, whose cache will then have to be cleared. If you don't like the idea of that, you can always create a table where you will update and store the analysis results, and then create fetches or operators to reach the data. This could even not be cached, if needed (provided you create a method that will make it possible to fetch a collection of relation counts in one SQL query). Just my random thoughts ;) Cheers, Piotrek -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Maxime Thomas	Sunday 18 May 2008 10:35:59 pm Hi, Maybe I have not understand totally what you want to do , but it seems that a fetch function will be the more efficient ? No ? Like a : fetch('content', 'relationlist', hash('parent_node_id', 'count', true() )) Maxime Thomas [email protected] \| www.wascou.org \| http://twitter.com/wascou Company Blog : http://www.wascou.org/eng/Company/Blog Technical Blog : http://share.ez.no/blogs/maxime-thomas
Piotrek Karaś	Sunday 18 May 2008 11:31:41 pm Maxime, Can you please elaborate on that solution, because I haven't been able to find that in the existing fetch list. Also, maybe it's not the best practice, but I try to put all the dynamic data (such as counters, grading/voting stuff) outside the main content model, because: a) it's dynamic, hence usually conflicting with cache b) it's expensive to reach for it from the data_map If you know a better practice for such stuff - please share ;) Cheers, Piotrek PS. Felix - what's your thoughts on that? -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Felix Laate	Monday 19 May 2008 12:59:13 am Hi again, I can't seem to find the fetch-function <i>relationlist</i> either. Would be nice though :-) I prefer keeping data like view counts separate as well, at least to a certain extend. But there are a few arguments against it. 1) it bothers me that there is no custom fetch function where I can tweak the very SELECT I'm looking for. I would like to see a way to define such function, much in the same way that fetch_alias works. 2) writing a script that does complicated counting and updates a table is a trivial task for an expert, but can be a hazzle for normal mortals. Obviously, counting is a real db-killer, as it takes alot of CPU. So doing counting each night, saving it in a separate table (or even database) and having optimized queries against it, is the most economic way to do things. Felix Publlic Relations Manager Greater Stavanger www.greaterstavanger.com
Maxime Thomas	Monday 19 May 2008 11:03:24 pm Actually it doesn'texist ! My purpose was to create it as custom fetch but as said Felix it is a kind of db killer feature. However, we can think to a precached query (I don't know if it is possible with MySQL) which allow you to cache the query after it has been runned. As it is a db mechanism, you don't have to care in the PHP part, you just make a normal query. Another point which is maybe interesting is the way we oragnize the code. We can make two queries, one for the count and if the count is greater tahn 0, we do the real fetch. Or, systematically do the real fetch and then count the results, so we use it or not. What is the best ? Maxime Thomas [email protected] \| www.wascou.org \| http://twitter.com/wascou Company Blog : http://www.wascou.org/eng/Company/Blog Technical Blog : http://share.ez.no/blogs/maxime-thomas