Pull to refresh

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.

Вы правы, такое решение тоже может быть, но оно не гибкое, так как данные агрегаты нужно будет "протаскивать" до места их использования.

Насчет ViewModel, а есть если вам нужны данные в Background Job? Данное же решение является универсальным и может быть использовано в любой части кода.

Only those users with full accounts are able to leave comments. Log in, please.