👤U
На самом деле, надо трезво оценивать. А нужно ли вам реально знать кол-во всех страниц?
Может, достаточно кнопок "туда, сюда"
Size: a a a
2020 December 18
ПГ
Ну у меня не кастомные репозиторий. . Хотя идея примерно как вариант 2. Получиь все данные самому и скормить пагинатору, чтобы просто использовать его интерфейс уровнем выше.
АЯ
Приветствую. Нубский вопрос )
В проекте кнп пагинатор, для него есть грубо говоря форматер для response. Не хотелось бы от этого уходить, т.е продолжать работать с пагинатором как про всему проекту.
Есть read запрос, там связи one-to-many. Запрос через коннекшн. Через пагинатор это не провернуть.
Как лучше поступить?
1) Прям в лоб, делаем запрос без релейшенов создаем пагинатор через paginationInterface->paginate(). Потом делаем еще запрос но уже с релейшенами, форматируем результат, подсовываем в items пагинатор
2) Создаем нативно пагинатор и заполняем его. Меньше запросов, но используется пагинатор КНП (ну или свой написать под интерфейс?).
3) Более правильное решение?
В проекте кнп пагинатор, для него есть грубо говоря форматер для response. Не хотелось бы от этого уходить, т.е продолжать работать с пагинатором как про всему проекту.
Есть read запрос, там связи one-to-many. Запрос через коннекшн. Через пагинатор это не провернуть.
Как лучше поступить?
1) Прям в лоб, делаем запрос без релейшенов создаем пагинатор через paginationInterface->paginate(). Потом делаем еще запрос но уже с релейшенами, форматируем результат, подсовываем в items пагинатор
2) Создаем нативно пагинатор и заполняем его. Меньше запросов, но используется пагинатор КНП (ну или свой написать под интерфейс?).
3) Более правильное решение?
Если какая то стороння либа вызывает сложности, то лучше её и не юзать. Единственное оправданное применение торонней либы - там всё наисано, там всё полюнятно и просто. Если возникают вопросы, значит либа не нужна.
ПГ
Если какая то стороння либа вызывает сложности, то лучше её и не юзать. Единственное оправданное применение торонней либы - там всё наисано, там всё полюнятно и просто. Если возникают вопросы, значит либа не нужна.
Сложностей сильных нет. Хочется элегантное решение.
СВ
ну это норм решение)
СВ
Неужели никто не юзает кнп пагинатор с через коннекшен в запорсах с one-to many связями ?
так а что там не провернуть то? чем one to many мешаеют?
ПГ
так а что там не провернуть то? чем one to many мешаеют?
Допустим 10 элементов, у каждого 10 связей. Это 100 строк из БД. Пагинатор посчитвает пагинацию от 100 строк а не от 10 . Ну и + надо еще как то это сложить потом в масив:
items[
item: {relations[]},
item: {relations[]},
item: {relations[]},
]
СВ
~разве пагинатор перед расчетом кол-ва join не уберет?~
да, для dbal не уберет..
да, для dbal не уберет..
ПГ
~разве пагинатор перед расчетом кол-ва join не уберет?~
да, для dbal не уберет..
да, для dbal не уберет..
он уберет для ORM так как знает какие связи, а для connection нет. так как это обычный запрос и он не знает что группироать и зачем.
СВ
ага, я уже глянул.. ну кажется проще, как я описал выше. и в рамках knp
ПГ
ага, я уже глянул.. ну кажется проще, как я описал выше. и в рамках knp
Ну это гидрация, "все дела" :) так то да, проще :)
СВ
не понял, какая гидрация в dbal ?
я пишу, что в рамках knp можно использовать callbacksubscriber - то что нужно вам, как мне кажется
я пишу, что в рамках knp можно использовать callbacksubscriber - то что нужно вам, как мне кажется
ПГ
не понял, какая гидрация в dbal ?
я пишу, что в рамках knp можно использовать callbacksubscriber - то что нужно вам, как мне кажется
я пишу, что в рамках knp можно использовать callbacksubscriber - то что нужно вам, как мне кажется
Ну наверное один из хороши вариантов. Чтобы не создавать нативно пагинатор. Но все равно придется писать запросы на каунт, и полный запрос на элементы. Грубо говоря вариант 2, но без нативного создания. Т.е. лучше.
VM
Допустим 10 элементов, у каждого 10 связей. Это 100 строк из БД. Пагинатор посчитвает пагинацию от 100 строк а не от 10 . Ну и + надо еще как то это сложить потом в масив:
items[
item: {relations[]},
item: {relations[]},
item: {relations[]},
]
а вытащить эти данные через орм нельзя, надо именно свой запрос через конекшен?