ханами не нужен

ханами не нужен

ты не нужен, кек

вот с логиками у рельсы проблема да, но как говорит ДХХ "рельсы это не ваш фреймворк" и кодеры смирившись с этим высказыванием прикручивают к рельсе треилблейзер )

ханами это фреймворк ради фреймворка за которым не видно продукта

вот с логиками у рельсы проблема да, но как говорит ДХХ "рельсы это не ваш фреймворк" и кодеры смирившись с этим высказыванием прикручивают к рельсе треилблейзер )

так трейлблейзер не работает

он не решает никаких проблем

(от слова совсем)

да чего, по структуре какраз решает

да чего, по структуре какраз решает

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

в этом беда

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

вот поэтому надо подбирать фреймворк под проект

ханами это фреймворк ради фреймворка за которым не видно продукта

есть аж 2 крупных продукта, так что ты как обычно не в тему :)

вот поэтому надо подбирать фреймворк под проект

не нужно

зачем?

на сколько крупных?

на сколько крупных?

ну dnsimple достаточно большой

а, еще прикол трейлблейзера в том, что он полностью легко заменяется dry стеком

Лорчую что trb не нужен

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

dry-стек - это что?

http://dry-rb.org

это набор инструментов для работы с функциональными объектами

хотя многие считают, что это rubyEE

ну да, вполне может заменить

впринципе никто не запрещает юзать вообще гемы поотдельности из которых и состоит и драй-стек и треилблейзер

синтаксис поприятнее, да, но Arel при необходимости облагородить не особо сложно

каким образом?

каким образом?

не приходится городить`Arel::Nodes::BindParam.new` и иже

не приходится городить`Arel::Nodes::BindParam.new` и иже

почеау не приходится?

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

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

Посмотреть в логи?

логи делейд джоба молчат

почеау не приходится?

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

логи стейджа несутся хз куда

крон раз в день

grep

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

хотя он может и выше по коду экранируется, но вряд ли

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

эм. Я чего-то запутался. Ты говорил, что arel при необходимости можно облагородить. А теперь получаетсяЖ. что его не надо облагораживать?

эммм

wat

про что конкретно был вопрос "каким образом?"

про "Arel при необходимости облагородить не особо сложно"

а

dsl накатать

ой, все

ну извините

если уж не dsl, то обернуть Arel::Nodes::BindParam.new и иже во что-то более короткое

dsl накатать

Нахуя?

dsl не всмысле dsl аля модели AR (i. e. всё не выглядит как код), а dsl аля более удобные методы для работы с раздражающими вещами

(модели AR — has_one, has_many и вот это всё)

возвращась к вопросу о шаринге сессии между доменами. Плохим ли выходом будет передавать access_token другому домену?

А как ты его будешь передавать?

хороший вопрос

может CORS?

нет, iframe и postMessage(), CORS и прочее тебя не спасёт если это не поддомены

а примерно по шагам как это реализовать?

https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00

тебя интересует самый простой кейс

cпасибо!

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

Привет Есть две модели со связью 1 к 1. Почему при model.create_association() не затирается из базы старая, хотя обычно должна? Поймал баг пару раз, но как только ставлю брейкпоинт - код начинает работать нормально и удалять прошлую запись

ERROR: S client not available

Возможно, кто-то просто сталкивался с подобным

локи и транзакции в помощь

wtf 1 к 1? belongs_to с обеих сторон?

Model has_one AnotherModel

с другой стороны belongs_to? Какие-нибудь валидации для них прописаны?

Лучше всего в БД уникальный индекс сделать, чтобы такого не было.

Нет, никаких вплидаций нет. С другой стороны belongs_to.

А почему старая должна затираться?

Так ведёт себя метод, который генерирует has_one. При создании новой автоматически удаляется старая

По крайней мере на моей памяти это автоматически всегда было

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

Спасибо за ответы

то бишь в твоём примере у AnotherModel есть model_id и если ты сделаешь another_model.create_association — оно перепишется и всё будет ок, если ты сделаешь model.create_association —- произойдёт (у вновь ассоциированной) another_model.model_id = model.id. У старого инстанса another_model ничего не изменится, он так же будет belongs_to.

ограничение в одну ассоциацию у тебя только с одной стороны

Только хочу поправить, что метод create_association вызывается не на another_model, а на model, так как это model has_one another model.

Сон поможет :)

ну вот, у прошлых model.another_model ассоциации остаются висеть.

Я работаю с одним объектом, их не много :) Реальный пример: Product has_one Attachment product.attachment.present? => true Нормальное поведение: product.create_attachment(params) # удаляет прошлый, записывает новый Поведение, с которым я столкнулся: product.create_attachment(params) # создает новый, старый остается висеть в базе просто так, и если мы этот новый attachment удалим, он (старый) станет на свое прежнее место и product.attachment будет возвращать старый соотв-но

Ладно, если я не смог объяснить проблему внятно, чтобы было понятно с первого раза адекватному человеку, то проблема явно во мне :) Поработаю над этим

Спасибо ?

Ладно, если я не смог объяснить проблему внятно, чтобы было понятно с первого раза адекватному человеку, то проблема явно во мне :) Поработаю над этим

да всё понятно, и на самом деле если для создания attachment'ов вызывается _только_`create_attachment` (а не другие методы) и проблем с сохранением никогда не бывает — всё должно быть ок. Другое дело что если старая модель не заапдейтилась — ой. Проверяется весьма несложно: https://gist.github.com/ojab/7709bc2c1a104ca4a880751eeb3df956 не позволяет обнулить старые ассоциации и при каждом create_another_model будет создаваться дубликат.

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

Спасибо!

Нужна помощь - не передаются аттрибуты в парамс из вьюхи в экшен, их там нет. Borrowers has_many payments, nested routes в routes.rb. borrower_payment_path передает в params только borrower_id, a нужно еще и id для payment: No route matches {:action=>"show", :borrower_id=>"5", :controller=>"payments"}, missing required keys: [:id] Мне нужно перейти по borrower_payment_path, а вылетает ошибка эта ошибка. Ниже гист - https://gist.github.com/AIexey-L/bf326079864ddc2684be8796019d2e1f

Нужна помощь - не передаются аттрибуты в парамс из вьюхи в экшен, их там нет. Borrowers has_many payments, nested routes в routes.rb. borrower_payment_path передает в params только borrower_id, a нужно еще и id для payment: No route matches {:action=>"show", :borrower_id=>"5", :controller=>"payments"}, missing required keys: [:id] Мне нужно перейти по borrower_payment_path, а вылетает ошибка эта ошибка. Ниже гист - https://gist.github.com/AIexey-L/bf326079864ddc2684be8796019d2e1f

дык эта

а где у тебя передается borrower_id в link_to?

#язабан

#язабан

ну нажми репорт

в канал зайди и нажми там report