Спасибо за валидный поинт! Да, к сожалению, не всегда это просто взять и добавить constraint, сначала нужно правильно "починить" данные. К сожалению, шаблоного подхода в этом быть не может, у всех свои ситуации, но что подходит в любом случае, так это не забыть добавить constraint после очередной починки данных, чтобы избежать повторной ситуации. Здесь же, как раз о таком больше и рассказано.
Вы правы, такое решение тоже может быть, но оно не гибкое, так как данные агрегаты нужно будет "протаскивать" до места их использования.
Насчет ViewModel, а есть если вам нужны данные в Background Job? Данное же решение является универсальным и может быть использовано в любой части кода.
Как вариант, можно ещё для graphql добавить примеры.
Вы правы, данные методы отлично смотрятся в использованием GraphQL, особенно в совокупности с ArLazyPreload. Это позволяет полностью избежать необходимости в написании Loader (исключением будут аргументы).
Но уже выше отметили, семантически смотрится, извините, пугающе. Ещё и в модели.
Если вы не используете ассоциации в моделях, тогда я бы и вправду не рекоммендовал добавлять внутрь моделей. К сожалению, по умолчанию, ActiveRecord способствует сильной связности между моделями, и данный гем продолжает эту идею решая проблему "сложных ассоциаций".
Вообще по заголовку я верил, но не надеялся, что вы продолжили идеи гема ar_lazy_preload, чтобы теперь в active record вообще не приходилось учитывать N+1 или что-нибудь типа того.
Так и есть, почему вы думаете что нет? Просто примеры изложены простые, и как я уже понял, очень плохие. В документации сказано про интеграцию с ArLazyPreload лучше. Но документация тоже плохая и будет переделана в ближайшее время.
Если вы же о чем-то конкретно другом, прошу, поделитесь, я открыт к улучшениям/переработкам.
N+1 всё так же нужно иметь в виду, всё так же он является проблемой.
Проблемой, которая теперь решается добавлением простого лоудера без необходимости тащить сторонние агрегаты наподобие ViewModels и прочее.
В любом случае, спасибо вам! Для себя, увы, не нахожу где и как применить.
Спасибо, сожалею, что я так плохо изложил суть и применение гема. Надеюсь вы сможете пересмотреть свою позицию. Я всегда готов ответить на вопросы/предложения.
Я понимаю о чем вы говорите, но, согласитесь, что left join не лучшее решение, например, если мы хотим очень много подобных вещей подгрузить. Сомневаюсь, что вы захотите, чтобы у вас был запрос с 20 left join и что это будет соизмеримо также быстро работать. Здесь же, запросы в сути своей остаются простыми.
Наверное, примеры не самые лучшие, так как очень простые, изначально, я таковые и взял, чтобы показать, что ActiveRecord такого простого не может, а здесь это возможно по аналогии с ассоциациями. Предположим, вы хотите обращаться в сторонний сервис по API за данными о заказах и API поддерживает batch запросы, тогда данное решение может пригодится.
На самом деле случае куда больше, но я согласен, иногда, в зависимости от требований, все может обойтись обычным left join. С другой стороны, не всегда это будет самым оптимальным по производительности.
В вашем случае, вы просто отключаете валидацию по умолчанию. Да, в итоге вы не будете делать SELECT запрос к базе данных на каждую из ваших связей. Но задача целостности базы данных все еще не решена, и в вашем случае, в базу данных можно будет сохранить все, что угодно. В случае же с гемом, вы получаете целостность, улучшенную производительность и совместимость с ActiveModel::Errors
Спасибо за валидный поинт! Да, к сожалению, не всегда это просто взять и добавить constraint, сначала нужно правильно "починить" данные. К сожалению, шаблоного подхода в этом быть не может, у всех свои ситуации, но что подходит в любом случае, так это не забыть добавить constraint после очередной починки данных, чтобы избежать повторной ситуации. Здесь же, как раз о таком больше и рассказано.
Thank you!
Thank you!
Вы правы, такое решение тоже может быть, но оно не гибкое, так как данные агрегаты нужно будет "протаскивать" до места их использования.
Насчет ViewModel, а есть если вам нужны данные в Background Job? Данное же решение является универсальным и может быть использовано в любой части кода.
Вы правы, данные методы отлично смотрятся в использованием GraphQL, особенно в совокупности с ArLazyPreload. Это позволяет полностью избежать необходимости в написании Loader (исключением будут аргументы).
Если вы не используете ассоциации в моделях, тогда я бы и вправду не рекоммендовал добавлять внутрь моделей. К сожалению, по умолчанию, ActiveRecord способствует сильной связности между моделями, и данный гем продолжает эту идею решая проблему "сложных ассоциаций".
Так и есть, почему вы думаете что нет? Просто примеры изложены простые, и как я уже понял, очень плохие. В документации сказано про интеграцию с ArLazyPreload лучше. Но документация тоже плохая и будет переделана в ближайшее время.
Если вы же о чем-то конкретно другом, прошу, поделитесь, я открыт к улучшениям/переработкам.
Проблемой, которая теперь решается добавлением простого лоудера без необходимости тащить сторонние агрегаты наподобие ViewModels и прочее.
Спасибо, сожалею, что я так плохо изложил суть и применение гема. Надеюсь вы сможете пересмотреть свою позицию. Я всегда готов ответить на вопросы/предложения.
Да, вы правы, решается, у всего есть несколько решений, здесь представлено одно из них без необходимости поддержки денормализированных данных.
Я понимаю о чем вы говорите, но, согласитесь, что left join не лучшее решение, например, если мы хотим очень много подобных вещей подгрузить. Сомневаюсь, что вы захотите, чтобы у вас был запрос с 20 left join и что это будет соизмеримо также быстро работать. Здесь же, запросы в сути своей остаются простыми.
Наверное, примеры не самые лучшие, так как очень простые, изначально, я таковые и взял, чтобы показать, что ActiveRecord такого простого не может, а здесь это возможно по аналогии с ассоциациями. Предположим, вы хотите обращаться в сторонний сервис по API за данными о заказах и API поддерживает batch запросы, тогда данное решение может пригодится.
На самом деле случае куда больше, но я согласен, иногда, в зависимости от требований, все может обойтись обычным left join. С другой стороны, не всегда это будет самым оптимальным по производительности.
Спасибо за отзыв! Приятно!
Спасибо за отзыв, а можете, пожалуйста, немного подробнее объяснить по семантической части решения? Что не так? Можно ли что-либо исправить/улучшить?
Спасибо за отзыв!
bundle exec database_consistency, так же есть поддежка overcommit.В вашем случае, вы просто отключаете валидацию по умолчанию. Да, в итоге вы не будете делать SELECT запрос к базе данных на каждую из ваших связей. Но задача целостности базы данных все еще не решена, и в вашем случае, в базу данных можно будет сохранить все, что угодно. В случае же с гемом, вы получаете целостность, улучшенную производительность и совместимость с
ActiveModel::Errors