Comments 14
Очень элегантное решение, спасибо!
решение технически хорошее, но семантически...
Большое спасибо за разбор данной проблемы. Будет интересно применить у себя в работе. Буду иметь ввиду данный гем и попробую вообще решение!
Извините, это всё вместо left join?
Я понимаю о чем вы говорите, но, согласитесь, что left join не лучшее решение, например, если мы хотим очень много подобных вещей подгрузить. Сомневаюсь, что вы захотите, чтобы у вас был запрос с 20 left join и что это будет соизмеримо также быстро работать. Здесь же, запросы в сути своей остаются простыми.
Наверное, примеры не самые лучшие, так как очень простые, изначально, я таковые и взял, чтобы показать, что ActiveRecord такого простого не может, а здесь это возможно по аналогии с ассоциациями. Предположим, вы хотите обращаться в сторонний сервис по API за данными о заказах и API поддерживает batch запросы, тогда данное решение может пригодится.
На самом деле случае куда больше, но я согласен, иногда, в зависимости от требований, все может обойтись обычным left join. С другой стороны, не всегда это будет самым оптимальным по производительности.
это вместо counter_cache мне кажется. Ну и ИМХО пример 2 также решается денормализацией
Как вариант, можно ещё для graphql добавить примеры.
Но уже выше отметили, семантически смотрится, извините, пугающе. Ещё и в модели.
Вообще по заголовку я верил, но не надеялся, что вы продолжили идеи гема ar_lazy_preload, чтобы теперь в active record вообще не приходилось учитывать N+1 или что-нибудь типа того. Но кликбейтный заголовок с реальностью не сошёлся, N+1 всё так же нужно иметь в виду, всё так же он является проблемой.
В любом случае, спасибо вам! Для себя, увы, не нахожу где и как применить.
Как вариант, можно ещё для graphql добавить примеры.
Вы правы, данные методы отлично смотрятся в использованием GraphQL, особенно в совокупности с ArLazyPreload. Это позволяет полностью избежать необходимости в написании Loader (исключением будут аргументы).
Но уже выше отметили, семантически смотрится, извините, пугающе. Ещё и в модели.
Если вы не используете ассоциации в моделях, тогда я бы и вправду не рекоммендовал добавлять внутрь моделей. К сожалению, по умолчанию, ActiveRecord способствует сильной связности между моделями, и данный гем продолжает эту идею решая проблему "сложных ассоциаций".
Вообще по заголовку я верил, но не надеялся, что вы продолжили идеи гема
ar_lazy_preload, чтобы теперь в active record вообще не приходилось
учитывать N+1 или что-нибудь типа того.
Так и есть, почему вы думаете что нет? Просто примеры изложены простые, и как я уже понял, очень плохие. В документации сказано про интеграцию с ArLazyPreload лучше. Но документация тоже плохая и будет переделана в ближайшее время.
Если вы же о чем-то конкретно другом, прошу, поделитесь, я открыт к улучшениям/переработкам.
N+1 всё так же нужно иметь в виду, всё так же он является проблемой.
Проблемой, которая теперь решается добавлением простого лоудера без необходимости тащить сторонние агрегаты наподобие ViewModels и прочее.
В любом случае, спасибо вам! Для себя, увы, не нахожу где и как применить.
Спасибо, сожалею, что я так плохо изложил суть и применение гема. Надеюсь вы сможете пересмотреть свою позицию. Я всегда готов ответить на вопросы/предложения.
В мире RoR проблема N+1 действительно является проблемой? Зачем тянуть модель базы данных непосредственно во View и там работать? Казалось, что более чистым и гибким решением будет в "логике" (в контроллере или в том, что вызывается из контроллера) выполнить необходимые запросы, а ответ представить в виде отдельного класса ViewModel.
N+1 больше не будет проблемой