поменять связь получилось таким вот способом def model_params params.require(:building).except(:type, :flat_types, :image_types, :building_assignment_types).permit! end

добавив ексцепт

Есть кто нибудь, кто работает в мультипоточном режиме puma?

есть

есть

Есть контроллер. Там инициализирую переменную потока, например, Thread.current[:my_var]. В контроллере есть сохранение объекта эктиврекорд в базу. Вот, а в модели в колбэке получаю доступ к переменной Thread.current[:my_var]. Как себя поведет такой код с мультипоточными серверами приложений puma, thin?

если это в рамках одного Request'a, то должно быть нормально

если между request'ами, то соотвественно будут другие данные, и нужно пользоваться внешними хранилищами

если между request'ами, то соотвественно будут другие данные, и нужно пользоваться внешними хранилищами

Я так понимаю у puma мультипоточность предполагает обработку одного запроса многими потоками. Поэтому ищу информацию.

нет, один запрос - один поток (если не создавать дочерних потоков внутри)

нет, один запрос - один поток (если не создавать дочерних потоков внутри)

Вот уже интереснее. Я такую информацию не нашла. Где нибудь в спецификации это написано? ?

>Puma then serves the request in a thread from an internal thread pool. Since each request is served in a separate thread, truly concurrent Ruby implementations (JRuby, Rubinius) will use all available CPU cores.

нет документации я не искал, но это просто не то что невозможно а очень сложно (один запрос несколькими потоками) - это нужно branch predict и другие штуки которые умеет только CPU

А чем тогда многопоточные сервера приложений по факту отличаются от однопоточных?

в случае с mri руби с потоков немного толку, ну а так то выше: > truly concurrent Ruby implementations (JRuby, Rubinius) will use all available CPU cores.

Ну чуть производительнее, за счет, того, что GIL не блокируют разные внешние запросы

например сетевые вызовы

а так, в целом, реальная конкуррентность будет зависеть от количества ядер CPU и запущенных puma processes, соответственно

любое IO по идее: база, чтение файлов, > сетевые вызовы

То есть физически в пределах запроса поток один и без проблем можно работать с переменными потока?

в случае с mri руби с потоков немного толку, ну а так то выше: > truly concurrent Ruby implementations (JRuby, Rubinius) will use all available CPU cores.

Что такое mri?

это сишный стандартный руби

это сишный стандартный руби

И в нем потоки не физические, а логические?

и общие переменные потока?

руби не поддерживает потоки на уровне ОС

можно добиться многопоточности на уровне ВМ например в jruby

руби не поддерживает потоки на уровне ОС

А что делает Thread.new?

формально - потоки логические и блокируемые, как сказали выше на все кроме IO

Ну явно не создает поток на уровне ОС)

если хочется настоящей паралельности на уровне OC, надо или создавать не потоки а процесы ("долго" и затратно по оперативе) либо работать с jruby (тоже так себе опыт)

либо не использовать руби

Ну явно не создает поток на уровне ОС)

у меня для тебя новости

Thread.new создаёт поток на уровне ОС

глобальные переменные это зло, если чтото надо и в контроллере и в сервисе и в модели - значит бизнес логика размазана по самое небалуй

либо не использовать руби

тоже вариант

Суть не в желании. Просто встал вопрос при ревью. Мне отказывают в использовании переменных потока объясняя тем, что puma, thin потоконебезопасные, да еще и многопоточные. А в многопоточных якобы я не смогу в модели получить доступ к переменной, что установила в контроллере (в пределах одного запроса). Никакой бизнес логики. Просто хочу сохранять id пользователя, который сохраняет что-то в базу.

врут

потоконебезопасные — это вообще непонятный термин применительно к app server'у

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

были баги такие...

это не другой поток, это данные с прошлого запроса, которые не очистили

в том же потоке, да

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

О_О

это не другой поток, это данные с прошлого запроса, которые не очистили

(или какая-то библиотека/гем выставили переменную во всех потоках, но это потоконебезопасные библиотеки, а не app server)

если рельса обновляется попробуй CurrentAttributes(но они тоже работают с переменной треда)

если рельса обновляется попробуй CurrentAttributes(но они тоже работают с переменной треда)

то за CurrentAttributes?

https://github.com/steveklabnik/request_store ~?

http://edgeapi.rubyonrails.org/classes/ActiveSupport/CurrentAttributes.html

люди имели параметры get запроса, которых у них быть не могло. ладно, это лирика. так что же мультипоточность пумы означает в итоге? оков будем иметь только если сами инициируем создание новых потоков:

http://edgeapi.rubyonrails.org/classes/ActiveSupport/CurrentAttributes.html

Спасибо большое. Эта штука с каких рельсов доступна?

https://github.com/steveklabnik/request_store ~?

в модели request недоступен

оу, вроде погорячился и в 5.2 будет

но я так понял оно на основе Thread.current работает

если проблема это записать в базу id юзера - то почему вообще идет речь о Thread?

Передать current_user в модель же

как его лучше передавать?

я хочу его в колбэке модели иметь

ну кстати а почему не передать явно?

Post.new(user_id: current_user.id) не?

я хочу его в колбэке модели иметь

в модели нету поля user_id ?

зачем вообще модели чтото знать о юзере, это не ее зона ответственности

after_save -> { LogRecord.create!(change: …, user: user) }

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

ойой

Не совсем. На создаваемый объект ведется журналирование действий над ним в другой сущности. Журналирование выполняется в колбэке. В модели поля user_id нет. У меня бывают не только пользователи, но и сотрудники(это другая сущность в системе), которые могут менять эти данные

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

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

+

Я в проекте, где все это уже есть. В модели есть несколько полей, которые хранят сотрудников разных ролей, которые над ними работали. Условно admin_id, manager_id. Все таки было. Мне просто нужно дописать журнал изменений.

def self.create_post(user_id, change:, etc:) Post.create(....) LogRecord.create(...) end

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

Вариант отрефакторить с нуля все не пойдет)

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

я по началу кстати из пхп всё охуевал что в модели нет доступа к юзеру в модели

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

таких точек слишком много. десятки. может и больше ста. не вариант вставлять сохрание лог записи после каждого места где что-то сохдается или меняется

тоже задачи на логирование действий были

так что либо колбэки либо сервисы. а как на сервисах такое реализовать?

ну сервис надо везде будет вставлять где запись идёт

сервис = concern?

или как?

таких точек слишком много. десятки. может и больше ста. не вариант вставлять сохрание лог записи после каждого места где что-то сохдается или меняется

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

таких точек слишком много. десятки. может и больше ста. не вариант вставлять сохрание лог записи после каждого места где что-то сохдается или меняется

тогда писать в объект который сохраняется, чтобы знать кто этот объект сохраняет, но это тоже не его отвественность

или сервис, по сути такой же метод но определен не в модели а в другом классе

есть еще очень простой вариант с attr_accessor который поможет вашему коллбеку найти своего юзера, но я его не напишу ибо это говнокод

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

ну вообще нормальная ситуация лол) была СРМ, не было сотрудников, ввели сотрудников, возникла необходимость логировать всё

можешь кстати попробовать с событиями что-нибудь приудмать

ну вообще нормальная ситуация лол) была СРМ, не было сотрудников, ввели сотрудников, возникла необходимость логировать всё

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

ну у тебя есть заказ, ты такой пишешь сохранение заказа через update там или save(как обычно) и вот тебе стало нужно писать автора изменения - измененяешь через одно место

народ, напомните пожалуйста, кидали тут ссылку на сайт где предлагаются задачки для желающих попилить OSS

http://www.ossboard.org/

cultofmartians.com

данкешон!

Если вопрос стоит в логировании данных, то можно использовать http://guides.rubyonrails.org/active_support_instrumentation.html#creating-custom-events

народ, напомните пожалуйста, кидали тут ссылку на сайт где предлагаются задачки для желающих попилить OSS

https://24pullrequests.com/

Если вопрос стоит в логировании данных, то можно использовать http://guides.rubyonrails.org/active_support_instrumentation.html#creating-custom-events

вот да, тоже хотел это скинуть, там при чем даже стандартные ивенты есть для записи в БД, но оно тоже не потокобезопасно

Если вопрос стоит в логировании данных, то можно использовать http://guides.rubyonrails.org/active_support_instrumentation.html#creating-custom-events

запись в базу и логирование в разных транзакциях БД делать не очень-то

логировани в базу?

прозреваю что оно в базу логирует, да

это типа запись активити а не обычный лог

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