Задача: есть справочник (новости, посты в блоге и т.п.) с именем posts к которому есть подчиненный справочник содержащий комменты с именем comments. Хочется отсортировать посты по числу комментариев, которые к нему относятся. Предположим, что идентификатор родительской записи в таблице comments хранится в поле parentid.
Прямого решения данная задача не имеет, поскольку система не может принять в макрос $News[]$ в качестве значения для ключа sort ничего кроме названия поля, которое должно быть в таблице с постами. Количество комментариев у нас нигде не хранится.
Решение: создадим это поле, назовем его nofc (number of comments) динамически. Примем что в форме у нас было поле $IN_postid$, которое содержало идентификатор поста в таблице posts. Добавим на страницу с результатом добавления записи в таблицу с комментами макрос $RegistrationConfirm[]$, который умеет обновлять поля в таблицах:
$RegistrationConfirm [source: posts; filter:id=$IN_postid$; action: update; set_fields_values: nofc=$RecordCount[source: comments; filter: parentid=$IN_postid$]$]$
Такая конструкция просто запишет в таблицу posts в поле nofc количество записей в таблице comments, которые в поле parentid имеют идентификатор поста, к которому в данный момент добавлен коммент. Теперь можно при выводе сортировать посты по полю nofc.
Минусом такого решения является то, что обновление данного поля будет происходить только при добавлении записи, а при удалении её через админзону останется старое значение. Выхода три - просто подождать пока к данному посту не добавят еще один комментарий и счетчик скорректируется, либо после удаления записи вручную перейти на страницу, которая обычно показывается пользователям после добавления записи (не очень удобно, т.к. нужно будет в URL указать идентификатор поста), либо скорректировать количество записей в поле nofc через админзону вручную. Для этого не забудьте добавить поле nofc в описание entity.
Из плюсов - нет никаких вложенных запросов и подзапросов, как это неминуемо было бы сделано в реляционной СУБД для определения количества записей "на лету" (берем базы без использования триггеров, так сможет каждый, только не на любой базе). То есть работать будет быстро. В условиях где удаляемых комментов немного по отношению к общему числу данное решение вполне приемлемо.
