плохой совет, потому что before_save в скоупе транзакции

И чем это плохо?

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

с калбеками проект даже среднего размера превратиться в такую Ж что потом офигеть можно будет

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

И чем это плохо?

Он скорее всего имеет ввиду что сам before_create не плох, а плох большая реализация через него, например, после добавления одного элемента должны вслед за ним добавляться и другие, вот реализовать это через before_create это плохо. Но если касается самого объекта и это мелочи, то можно делать это через before, например, тебе надо сохранить имя большими буквами, тогда делаешь через before

ну там явно написано потому что before_save в скоупе транзакции

так что понятно, что имеется в виду

непонятно почему

Например, допустим при создании элемента A нужно создать и элемент B, а для этого в модели A через after_create ты прописываешь код создания элемента B. И ты создаешь элементы A в контроллере когда хочешь и сколько хочешь, и все работает как нужно. Но может прийти новый программист и создавать элементы A для других целей, а он и не заметит что создаются элементы B.

Но тут не надо создавать никакие B, а надо выставить аттрибут у А. И непонятно, почему это плохо в скоупе транзакции, и неплохо вне это скоупа.

Доброго времени всем! Горит диссер, нужна помощь технарей?? Собираю данные для исследования, не хватает людей в выборке профессий типа человек-знаковая система. Что нужно? Пройти тест, достаточно объемный, не самый веселый, займёт около 30 минут. Очень прошу потратить немного вашего времени и помочь мне в моем деле! В ответ буду очень признательна! https://goo.gl/BV415T Участие в исследовании добровольное, если вы устали проходить тест или вам надоело, просто закройте ссылку

Как вызвать rake task с админки, по нажатию на кнопку ?

Как вызвать rake task с админки, по нажатию на кнопку ?

хочешь чтобы у тебя админка подвисла пока rake task выполняется?

либо так, либо воркер зашедулить

запили в виде сервиса/команды и вызывай из таска/контроллера

зачем это в сервис инкапсулировать не очень понятно.

запили в виде сервиса/команды и вызывай из таска/контроллера

так и делаю, в отдельный экшен помесил

хочешь чтобы у тебя админка подвисла пока rake task выполняется?

заказчик предупрежнен)

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

Rake::Task['db:migrate'].reenable # in case you're going to invoke the same task second time. Rake::Task['db:migrate'].invoke

предлагаешь все-таки делать таск, и вызывать с помощью invoke?

предлагаешь все-таки делать таск, и вызывать с помощью invoke?

Если оно ЕЩЕ НЕ таска - лучше вынести в сервис.

Тестировать проще.

еше не таск, но логика такая: Достаем список сущностей - вызываем сервис для каждой

это обязательно надо инкапсулировать?

бизнес-логика какая - выплата депозита по каждому юзеру. Если что-то отвалится в процессе, то можно будет продолжить с того момента, где оборвалось. выплата по одному юзеру - это сервис

выплату по всем инкапсулировать не обязательно

бизнес-логика какая - выплата депозита по каждому юзеру. Если что-то отвалится в процессе, то можно будет продолжить с того момента, где оборвалось. выплата по одному юзеру - это сервис

есть сайдкик и ретраи

всем привет ребят если есть надобность в i18n для определенных таблиц, то есть записи в ней могут быть в нескольких языках, как лучше это реализовать? (учитывая что в перспективе количество языков вырастет) для каждого языка создавать новую запись ? и как её связывать с конкретным языком ? создать ещё одну таблицу и сделать reference, или хранить языковую аббревиатуру будет более предпочтительно ?

всем привет ребят если есть надобность в i18n для определенных таблиц, то есть записи в ней могут быть в нескольких языках, как лучше это реализовать? (учитывая что в перспективе количество языков вырастет) для каждого языка создавать новую запись ? и как её связывать с конкретным языком ? создать ещё одну таблицу и сделать reference, или хранить языковую аббревиатуру будет более предпочтительно ?

https://github.com/globalize/globalize

https://github.com/globalize/globalize

спасибо ?

ребят, никогда не работал с енамами в хуках

это норм, что я получаю вечный луп, когда меняю их в before_create?

псевдокод

class User < ApplicationRecord enum activation_state: %i[pending active] before_create :change_state private def change_state self.pending! end end

получаю ошибку stack level too deep

и луп запросов, которые он пытается сделать 1 за другим

pending! вызывает update!, который вызывает create!, очевидно.

(который вызывет коллбек, да)

оу

лол,кек, костыльно енам описывать придётся

нет, достаточно написать state = :pending вместо self.pending!

enum activation_state: [ PENDING = 0, ACTIVE = 1 ]

окей, тогда сначала надо почитать документацию по rails enum и сделать по-нормальному.

ну и activation_state = PENDING

чем то, что выше я написал не нормально? Не так, как в доках рельс? Так многое лучше делать не так, как в доках ?

код enum activation_state: [ PENDING = 0, ACTIVE = 1 ] делает непонятно что и вряд ли ты на самом деле понимаешь, что он делает.

код enum activation_state: [ PENDING = 0, ACTIVE = 1 ] делает непонятно что и вряд ли ты на самом деле понимаешь, что он делает.

присваивание возвращает значение присваивания, следовательно я говорю, что значения енама могут быть 0 и 1. Работает также. Ключевой недостаток - потом AR вернёт 0 вместо внятного описания состояния

а зачем ты тут константы PENDING и ACTIVE объявляешь?

в проекте не принят какой либо стайлгайд поэтому не важно где их обозначать

а зачем они тебе нужны?

просто так чтоб были?

а что мне скажут 0 и 1 в коде?

А чем enum activation_state: %i[pending active] не устроил?

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

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

enum activation_state: { pending: 0, active: 1, } и делаешь спокойно r.activation_state = :pending

Коллеги погромисты, вопрос такой: если в экшенах контроллерах есть одинаковые переменные присваивания, то как заDRYить?

А точнее не одна переменная, а несколько.

Бифо экшн: сет_вараябл

Вообще лучше вместо рельсового енама возьми сразу асм

И в приватном методе сет_вараябл устанавливает нужные щначения

ERROR: S client not available

Бифо экшн: сет_вараябл

вот не люблю такое. обычно делаю в каждом экшне @var = var сам метод приватным делаю или даже просто def var @var ||= end

вот не люблю такое. обычно делаю в каждом экшне @var = var сам метод приватным делаю или даже просто def var @var ||= end

зачем ты это пишешь, когда есть attr_accessor

зачем ты это пишешь, когда есть attr_accessor

мы же по контроллер

мы же по контроллер

и что?)

допустим у тебя есть какая-то штука типа @post = Post.find(params[:id])

и она в трех экшнах

соответственно я делаю метод def post @post ||= Post.find... end

Ребята, это когда не одна переменная, а три и более...

и везде его использую

Ребята, это когда не одна переменная, а три и более...

три переменных - три метода

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

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

Тогда и так сложно понять что откуда берется. Смотришь на контроллер - там пусто, открываешь view - а там три переменных.

А Presenter для контроллера есть такое? Логично? Удобно?

А Presenter для контроллера есть такое? Логично? Удобно?

ну можно что-то типа def show @data = Presenter.new(post, current_user, some_other) end

аргументы - приватные методы

в вьюхе используешь все от @data

все понятно откуда что берется

Сенди Метц вообще считает что из контроллера во вьюху только одну переменную можно передавать

типичный фасад или презентер

Сенди Метц вообще считает что из контроллера во вьюху только одну переменную можно передавать

Можно хэш или OpenStruct передать)

Типичный фасад - имеешь ввиду декоратор?

Можно хэш или OpenStruct передать)

ну да. это уже детали имплементации

Типичный фасад - имеешь ввиду декоратор?

фасад, декоратор, презентер - это все примерно одно и то же. одно является частным случаем или реализацией другого

ну да. это уже детали имплементации

Это был шутка. Передавать хэш тоже самое, что передать много переменных. У хэша нет интерфейсас. Как и у OpenStrcut

Это был шутка. Передавать хэш тоже самое, что передать много переменных. У хэша нет интерфейсас. Как и у OpenStrcut

да, хеш не годится. опенстракт имеет интерфейс же

Типичный фасад - имеешь ввиду декоратор?

Draper

да, хеш не годится. опенстракт имеет интерфейс же

Он меняется на лету, не считается

Какой гем используете для geoip?

Есть georuby

и как я в нём могу получить страну, город по ip?