You can create your own extended attribute filter and fetch waht you need. But its demand some study of database structure.
This is join which enables sorting by comments count. Where ezcontentobject.contentclass_id = '13' is comments classID.
NATURAL LEFT JOIN (SELECT DISTINCT
parent.contentobject_id AS contentobject_id,
Count(ezcontentobject.id) AS comments
FROM
ezcontentobject_tree AS childTree
Inner Join ezcontentobject_tree AS parentTree ON rodicTree.node_id = childTree.parent_node_id
Inner Join ezcontentobject_name AS parent ON rodic.contentobject_id = parentTree.contentobject_id AND parent.content_version = parentTree.contentobject_version
Inner Join ezcontentobject ON ezcontentobject.id = childTree.contentobject_id AND childTree.contentobject_version = ezcontentobject.current_version
WHERE
ezcontentobject.contentclass_id = '13'
GROUP BY
rodic.name,
rodic.contentobject_id) as comments
If you add ,comments.comments as comm_count to the columns you can sort by count of comments. This is the way to fetch most commented object...
The sql above will most likely be very slow, I think it would make more sense to do a completely separate sql call when doing advance stuff like this, and not hook into tree / list fetch witch can already be a bit heavy on it's own.
2 examples ( fetchNodeByRating() and getRatingWhere() ): http://svn.projects.ez.no/ezcore/trunk/ezcore/autoloads/ezrating.php
Object-relations is a very complex and multi-level datatype, and so are queries to the eZ content model. I think you should aim at providing a dedicated datatype with its own one database table as a storage. You would simply keep references from an object to an object, with creation date, user ID and other useful information. Even if you have a million article selections, this should still be possible to maintain, query, etc. You can also provide template operator or a fetch for querying it from within templates.
