tndt-19 в ревью. И теперь мы ниак не зависим от knp, и эту задачу можно и добить. Другой вопрос что нужены ли нам эти колонки в принципе? Кажется, что не очень. А когда мы решим их добавить, наример в документах, они стоят просто, чтобы пусто не было, нам их все равно заного писать и проверять, так что задача в принципе не актуальна.

up, чтобы не потерять когда мы будем делать tndt-19

Все еще ждем tndt-19 и все еще ошибка виси и ждет. И в документах то же ждет.

Несмотря на компактность, она совсем не легкая

Вспомнили, уткнулись и даже подумали, что это введение спецификаций так повлияло. Надо бы тоже заняться. Даже если мы поправим её в задачах, в документах менее приоритетно и висеть будет

Думается поправиться при переделке фильтрации и сортировки, так как сортирорваться будет уже не встроенной штукой, а нашими сервисами, которые знают, что это поле в join

Решится в рамках tndt-19

На всякий случай попробовал победить это, оставив knp, путем сортировки по подчиненной таблице, и добавив join на неё в query. Это не помогло, да же если бы и помогло, делать join только ради того, чтобы отсортировать по полю, которое и так есть в исходной таблице, зачем?

Короче я пока за то, чтобы сделать свой пагинатор. Поддержка горы движков и вариантов коллекций мне без надобности здесь, сложная сборка условий и сортировок по запросу и так надо будет реализовать, а уж вычислить и добавить limit/offset по номеру страницы и общему count я и сам могу.

Да, в документах сортировка по автору так же не работает, и что еще печальнее эти столбы там есть, ибо больше никаких особых атрибутов у документов нет

А может забить на эту задачу, все равно при реализации tndt-19 я почти наверняка уйду от knp пагинатора в свой.

Что-то у нас уже гора таких задач, стит их проверить, все, починить и позакрыть?

Приоритет низкий так как пока мы работаем в проекте в одиночку эти столбцы вобще не имеют смысла