что-то у меня не выходит

так я то же самое написал)

у меня вариант короче. Особенно если какой Post.transaction

ну и опять же, семантически подчеркивает ради чего транзакция.

а не просто сам факт.

у меня вариант короче. Особенно если какой Post.transaction

это ОДИН И ТОТ ЖЕ МЕТОД

может потому, что в AnotherModel.save на самом деле выполняется def save blah blah OneMoreModel.save blah blah end

save!

лол, патчить save метод

мне кажется ты пилишь грандкостыль

AnotherModel - это не ActiveRecord

это бизнес-модель. :)

А вот OneMoreModel - это уже AR

https://www.sitepoint.com/complex-rails-forms-with-nested-attributes/

а, окей.

Вообще для такого обычно юзают что то вроде Reform

угу

это ОДИН И ТОТ ЖЕ МЕТОД

Спасибо кэп.

я вот прям не знал что это один и тот же метод, хех.

Я говорю семантически корректнее.

Полезу гуглить сейчас про Reform. Но вот, если в общем, в моем случае .transaction должна работать?

Спасибо кэп.

в каком AR классе его вызывать - без разницы, если он отнаследован. Можешь отнаследовать хоть однобуквенный класс и говорить "так короче, кококо"

в каком AR классе его вызывать - без разницы, если он отнаследован. Можешь отнаследовать хоть однобуквенный класс и говорить "так короче, кококо"

Погугли что такое семантика хорошо?

Полезу гуглить сейчас про Reform. Но вот, если в общем, в моем случае .transaction должна работать?

ты сейчас рискуешь запилить архитектурный костыль который потом будет больно исправлять.

ты сейчас рискуешь запилить архитектурный костыль который потом будет больно исправлять.

что именно?

патчинг save метода в модели

это транзакция ActiveRecord. К имплементации конкретно ЭТОГО класса это не имеет ни малейшего отношения в общем случае.

у меня нет патчинга метода save в ar-модели

у меня есть NonAR1 в которой делается NonAR2.save в котором, в свою очередь, делается AR.save!

это транзакция ActiveRecord. К имплементации конкретно ЭТОГО класса это не имеет ни малейшего отношения в общем случае.

Ты правда хочешь поспорить? хорошо. Post.transaction do post.title = 'wtf' PostPic.transaction do pics.each(&:save!) end end

Это читабельнее. Это задает семантический контекст, ради чего создавалась транзакция вообще. Это короче.

у меня есть NonAR1 в которой делается NonAR2.save в котором, в свою очередь, делается AR.save!

connection в БД один и тот же используется?

Да, конечно

Там с БД связан только AR.save! остальные классы к базе не лезут

Ты правда хочешь поспорить? хорошо. Post.transaction do post.title = 'wtf' PostPic.transaction do pics.each(&:save!) end end

это говнокод

PostPic.transaction do pics.each(&:save!) end

говнокод это ActiveRecord::Base.transaction

в класс PostPic

отдельным методом

это абстрактный пример, лол

ты правда думаешь что я буду сейчас реальный пример ради тебя разрабатывать?

и там ActiveRecord::Base.transaction

ты не приведешь нормальный пример с вложеной транзакцией в одном месте

интересный подход с Model.transaction, забрал себе

потому что это разные класс

ы

ты не приведешь нормальный пример с вложеной транзакцией в одном месте

У меня таких два или три случая было.

Это разные модели. У поста есть много фоток

я уверен, что их можно написать нормально

Я тебе еще раз говорю что это псевдокод

Я правда не желаю тратить время на написание реалистичного кейса, потому что он будет больше.

тогда о чем речь? Я говорю про общий случай. В общем случае ActiveRecord::Base.transaction достаточно. Сразу ясно, что это, откуда, куда смотреть в доках.

это и по названию очевидно что это. Однако если у тебя вложенная транзакция, это уже начинает пахнуть.

вложеная транзакция пахнет по определению

Там с БД связан только AR.save! остальные классы к базе не лезут

А что мешает сначала всё провалидировать, а потом сохранить если валидации прошли?

ну и опять же, оно банально длинее, мне вот лень длинно писать и вспоминать что там за класс.

вложеная транзакция пахнет по определению

еще скажи так не бывает :)

А что мешает сначала всё провалидировать, а потом сохранить если валидации прошли?

прекрасный вопрос, сейчас так и сделано. Но это сработает только в случае ошибок валидации. В случае любых исключений случится косяк

еще скажи так не бывает :)

говно случается. Просто класс может быть,к примеру, Namespace1::Namespace2::Foo

А при откатывании изменений исключение не может случиться?

Ибо это то же сохранение, по сути.

говно случается. Просто класс может быть,к примеру, Namespace1::Namespace2::Foo

тройной неймспейс модели тоже пахнет по определению.

тройной неймспейс модели тоже пахнет по определению.

нет, просто большой проект

приведи пример подобного названия.

А при откатывании изменений исключение не может случиться?

ну поидее в базу просто посылается rollback если не вложенное. Там особо нечему происходить.

ну поидее в базу просто посылается rollback если не вложенное. Там особо нечему происходить.

А при чём тут база вообще?

приведи пример подобного названия.

Marketing::EmailManager::Mailer, к примеру =)

ERROR: S client not available

у тебя в блоке транзакции происходит ошибка - блок прекращает выполняться, при выходе из блока AR шлет rollback

не понимаю твоего вопроса тогда.

Marketing::EmailManager::Mailer, к примеру =)

это модель?

да, была такая модель на одном проекте

Там с БД связан только AR.save! остальные классы к базе не лезут

у тебя в блоке транзакции происходит ошибка - блок прекращает выполняться, при выходе из блока AR шлет rollback

^

Emails::Domens::DayStat

у питонистов даже есть правило

типа много неймспейсов не бывает

ну, мы не питонисты. У рубистов и рельсовиков многое по другому.

Алсо я не знаю бизнеслогику твоего проекта но мне кажется что название твоей модели можно было бы упростить.

в этом отношении все похоже у нас

ну блин, понимаешь, когда моделек штук 300

их надо куда-то девать

хранить все под одним неймспейсом это суицид

тем более, если они начинаются одинаково

и в одной области логики лежат

мне кажется, когда так много моделек, уже логично бить проект на куски.

расскажи это бизнесу, ага)

Архитектор кто? ты.

бизнесу нужно решение задач.

переписать большой проект на куски это куча бабла

тем более, что нам и так норм

в монолите

а Hanami сырой еще)

что в том ханами такого особенного?

там DDD

спецом для крупных проектов

а Hanami сырой еще)

ну уже 1.0.0beta вышел жи

ну уже 1.0.0beta вышел жи

ну мы-то понимаем)

1.0.0beta == анальная боль

ну они пообещали не менять апи - значит, можно начать потихоньку пилить на него переход