ну и нормальная ОРМ

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

ну и нормальная ОРМ

А есть где почитать про нормальность/ненормальность ОРМ для ненастоящих сварщиков?

тем, что там больнее

а вот хз, мне сейчас от рельсы большее, но это лично мое мнение

А есть где почитать про нормальность/ненормальность ОРМ для ненастоящих сварщиков?

ничего не понял

можно почитать доки ханами например

http://hanamirb.org/guides/models/overview/

вот от сюда

Ребята, привет! Кто уже начал пользоваться Hanami, есть ли у него реальные преимущества, стоит ли его рассматривать уже сейчас как альтернативу?

а, ну и TLDR: используй, не думай. не понравится - успеешь выкинуть и переписать на то, что нравится

ничего не понял

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

а вот хз, мне сейчас от рельсы большее, но это лично мое мнение

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

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

разогнулись, лол

да не

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

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

с докой все плохо (хуже чем с АР), поэтму почитай гайды, ссылка выше. И советую посмотреть на репозитории в реальных проектах

будет видно что и как работает там

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

но у рома есть пара минусов: 1. он не очевидный местами и по началу будет больно 2. когда боль уходит, становится больно с остальным

Ребята, привет! Кто уже начал пользоваться Hanami, есть ли у него реальные преимущества, стоит ли его рассматривать уже сейчас как альтернативу?

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

Мое ИМХО, что если ты начинающий проггер, который ищет работу, то под рельсу работу найти проще

ханами можно посмотреть из интереса, но если он тебе реально не сильно нужен и уже есть опыт с рельсой, то запилить проект на рельсе проще и быстрее

а вот если есть хорошая работа и там есть ханами, то не грех и выучить

Мое ИМХО, что если ты начинающий проггер, который ищет работу, то под рельсу работу найти проще

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

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

писать не говнокод на рельсе помогает код ревью )

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

писать не говнокод на рельсе помогает код ревью )

неа

говорю по собтсвенному опыту

на первой работе доебывались к каждому символу на ревью. это вообще никак не помогало писать хороший код

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

но это мой личный случай

можно еще раз про интеракторы? что это такое? чем-то отличается от сервисов/команд/операйшн/etc?

Получил предложение писать о том, что использую в ежедневной работе, и добавить больше юзкейсов. Давайте попробуем. В последнее время я часто использую паттерн interactor, поэтому расскажу о нем подробнее и покажу на реальном примере, как с помощью этого подхода зарефакторить экшен. Я фанат идеи функциональных объектов. В Rails я использовал сервис-объекты, в текущем dry-web проекте — оперейшены, а в ханами — интеракторы. Текст будет касаться исключительно Hanami и hanami-interactor, но подход возможно использовать в других фреймворках.

вот тут читай

там много и с примерами

вот ссылка даже https://t.me/pepegramming/16

спасибо

хм, ссылки работают в разы лучше

спасибо

там же дальше про базовый DI будет

Спасибо всем за ответы. Я хочу организовать команду фрилансеров. Фрилансеры, поделитесь, плиз, опытом, кто где ищет заказчиков?

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

покажи реальный пример где справляется hanami orm и не справляется активрекорд? не защищаю рельсу, просто интересно

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

я дальше буду писать про это

буду ждать :)

т.е. пока описывалась сама идея, скоро напишу про dry-containers, а потом про dry-system, а вот там прямо заходит на ура

покажи реальный пример где справляется hanami orm и не справляется активрекорд? не защищаю рельсу, просто интересно

у меня нет примеров прямо сравнения

хорошие фрилансеры сидят на upwork и хотят зп в еврах

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

ну как самый простой пример, ILIKE постгреса

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

в АР из коробки нет этого

в роме есть

аналогично с нормальным чейном запросов

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

хм, у меня нет прямо БОЛЬШИХ запросов, сейчас найду что-нибудь большое

есть большой метод для разного поиска по полям

вот так выглядит https://github.com/davydovanton/octostar/blob/master/lib/octostar/repositories/project_repository.rb

и то, я бы мб его переписал сейчас

в 24 строке OR симпатичный

ага, not тоже норм выглядит

в роме есть

http://www.rubydoc.info/gems/rom-sql https://github.com/rom-rb/rom/search?utf8=%E2%9C%93&q=ilike&type=

пичалька

вот так выглядит

[3] pry(main)> repo.accounts.where { email.not('123@test.com') } => #<Persistence::Relations::Accounts name=accounts dataset=#<Sequel::Postgres::Dataset: "SELECT \"id\", \"status_id\", \"email\", \"created_at\", \"updated_at\", \"deleted_at\" FROM \"accounts\" WHERE (\"email\" != '123@test.com') ORDER BY \"accounts\".\"id\"">>

http://www.rubydoc.info/gems/rom-sql https://github.com/rom-rb/rom/search?utf8=%E2%9C%93&q=ilike&type=

https://github.com/davydovanton/octostar/blob/master/lib/octostar/repositories/project_repository.rb#L24

https://github.com/davydovanton/octostar/blob/master/lib/octostar/repositories/project_repository.rb#L24

это я вижу, я не вижу где оно реализовано в rom и иже

вот это уже не ко мне :D

меня терзают смутные сомнения что там method_missing или подобное, так что об "изкоробке" говорить не совсем корректно

ERROR: S client not available

ну а в целом, у меня, спустя 2 года, сложилось такое мнение обо всем этом: если вы чувствуете какое-то давление со стороны рельсы или понимаете, что много времени тратите на то, что бы побороть фреймворк - попробуйте ханами или dry-web. скорее всего вы почувствуете себя свободнее

скорее всего на самом деле

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

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

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

ты часто на арел писал?

ну и, прозреваю, arel помощнее будет

приходилось периодически

ну и, прозреваю, arel помощнее будет

вот тут не уверен

ну и арел прямо не читаем в 90% случаев

Парни, привет. Как можно добавить в relation элемент во время выполнения скоупа? если проверять возвращаемое кол-во, такое ощущение, что возвращается кэширование значение и relation не изменился, хотя внутри скоупа он меняется.

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

а, ну и главный плюс - маппинг данных быстрее

А что ты пытаешься этим сделать? Relation не массив.

так как в энтити нет ничего лишнего

ни валидации, ни каких-то колбэков

А что ты пытаешься этим сделать? Relation не массив.

Я согласен что не массив, однако методом « можно добавить значение

В общем в relation домержить запись надо при опред. условиях

ну и арел прямо не читаем в 90% случаев

прозреваю что в 90% случаев или проблема не в ареле, или на роме получится не сильно лучше

прозреваю что в 90% случаев или проблема не в ареле, или на роме получится не сильно лучше

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

В общем в relation домержить запись надо при опред. условиях

relation — результат выполнения запроса, туда нельзя мержить записи

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

В общем в relation домержить запись надо при опред. условиях

ты так и не ответил, что в итоге хочешь получить. Возможно тебе поможет testscope.to_a + result.

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

звучит вполне логично

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

Как бы ORM и созданы для того чтобы сырой SQL не писать и не читать. Arel по сути и есть сырой sql обёрнутый в объекты, что позволяет более-менее удобно оперировать кусками сложных запросов.

нужно чтобы скоуп возвращал всегда reletion оригинальный или измененный (если передан параметр).

Тебе точно нужен Realtion, а не Array, например?

просто есть места где его используют в связке с другими скоупами и все поломается если будет Array)

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

Подсказка: его можно использовать с другими scope'ами, потому что это результат sql-запроса и к нему можно надобавлять ещё sql'a. Добавление произвольной записи это ломает.

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

коммерческая проблема - проблема новой технологии. за последний год интереса и спроса стало в разы больше, так что это просто дело времени скорость - тут не только про скорость самого кода (хотя бенчмарки получаются в 2-3 раза быстрее минимум), а про скорость разработки (не сколько начальной, а уже после "бурста). и тут получается достаточно все красиво, ибо разделение логики сильно спасает