Уточнения по методу group.

[bochsdbg]

В текущем описании метода group есть две неточности

1. Нет описания конкретных полей для выборки (фильтрации). По сути все, что написано:

необходимо выполнить выборку как в предыдущем запросе, но по конкретным значениям, а не по предикатам (...) Выборка может идти по любому полю, но значение в нём будет только одно.

Здесь есть множество неочевидных моментов. Скажем, указано, что в birth идет год, т.е. мы выбираем действительно аналогично методу filter, email и phone я в тестовых данных не увидел, но "по аналогии" они должны фильтровать домен и код телефона, соответственно (т.к. сравнения на равенство в методе filter не предусмотрено), верно? Хорошо, тогда что должно быть выбрано, если указан ключ premium? Или же это невалидный ключ? Поля joined в фильтре вообще нет -- т.е. мы опять же, не можем действовать "по аналогии" (хотя тут из тестовых данных очевидно, что joined -- это год). В общем, не мешало бы тут четко указать список возможных полей, чтоб можно было строго валидировать запрос. Либо же указать, что список возможных параметров стоит брать из пункта 2, где описана структура аккаунта, а такие-то и такие-то являются невалидными. Для нескалярных значений нужно показать, как их сравнивать. Если есть какая-то прямая аналогия (если не хочется раздувать список полей), лучше ее задать явно: birth действует как birth_year, а email аналогично email_domain итд -- это будет гораздо нагляднее и понятнее.

2. Уточнить порядок сортировки при выводе, когда count одинаковый.

В ответе могут получиться группы с одинаковым count и это может создать проблемы на этапе валидации ответов. Пожалуйста, сортируйте такие группы между собой по значениям других полей в порядке, заданном order.

Когда у нас в keys указано несколько полей, то неизвестно, какие поля являются более приоритетными, какие менее. Например, группируем с keys=sex,country, в условном sql-запросе мы запишем: ORDER BY count, sex, country. Или же ORDER BY count, country, sex. А может, порядок следования полей под ORDER BY будет зависеть от параметра order (который по задумке должен влиять только на DESC/ASC суффиксы в sql запросе, но не на порядок их следования) -- этот момент неоднозначен. Ясное дело, проявляется он довольно редко, вероятно, даже не в каждом рейтинговом датасете, но именно этим он и опасен, т.к. на редкие случаи обычно тестов пишется меньше и может оказаться, к примеру, что валидатор будет это делать случайным образом. Или, возможно, он имеет какой-то свой фиксированный порядок следования этих параметров (скажем, статический запрос вида ORDER BY count, sex, city, country, status) -- без знания этого порядка можно внезапно получить редкие, а потому весьма трудноуловимые ошибки.

2.5. В чате я уже несколько раз встречал вопрос, как группировать по key=interests. Лично я (по крайней мере сейчас, пока еще не начал реализовывать этот метод) не вижу с этим ключом никаких проблем, но, вероятно, стоит сделать хотябы минимальные разъяснения в документации, по этому поводу?

[SannikovDmitry]

Выборка может идти по полям sex, status, country, city, birth, interests, likes, joined, но значение в нём будет только одно (для likes будет только один id, для interests только одна строка, для birth и joined - будет одно число - год). Возможные значения для данных полей перечислены в таблице.

Название поля Возможные значения

sex        выбрать всех, чей пол равен указанному;
status      выбрать всех, чей статус равен указанному;
country      выбрать всех, кто живёт в данной стране;
city      выбрать всех, кто живёт в данном городе;      
birth      выбрать всех, кто родился в указанном году;
interests    выбрать всех, у кого есть данный интерес; (в значении - одна строка);
likes      выбрать всех, кто лайкал данного пользователя; (в значении - один id);
joined      выбрать всех, кто зарегистрировался в указанном году;

Порядок сортировки - в начале по count, затем по полям в keys, в порядке, в котором они перечислены в keys.