Как же все-таки Ruby с Rails (в особенности) расслабляет да? Ни о чем думать не надо - клепай из компонентиков уже написанных гемов проекты и живи спокойно. Не подумайте ничего плохого - сам с 2009 года на Rails (и до сих пор)… просто привыкли к тому что фреймворк все сам за нас делает, вот и непривычно ручками все делать 😉

думаю, что на honeysql тоже можно напилить похожих абстракций, просто ни у кого руки не дошли все правильно обобщить

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

с любым фремворком, не только с рельсами...

спасибо) учу clojure понемногу)

https://github.com/edvorg/yet-another-craft

Воу, почему мне пришла нотификация без mention?)

потому что слак тупо ищет подстроку

представь, сколько мне нотификаций приходит, когда сниппеты вьюшек постят )))

мне немного проще :)

@kirillov: да клепаешь пока не надо внутрь тут либо вначале думаешь, либо потом "не знаешь что и думать". Реализовать большую часть магии ORM на clojure не очень сложно, если понимаешь как она работает

Проект простой: «оперировать запросами напрямую, фу». Прошло два года: «ух ты, всё нужное вытаскивается одним эпичным запросом». Может, и не в проекте дело.

@kirillov: поддерживаю абсолютно, с недавнего времени начал понимать, как много вещей в рельсе мы принимаем как должное, сам хотел дать такой ответ, но это же грустно. вот приходит новичок а @nicola ему "можешь для этого парочку generic хэлперов” 😕 нужны примеры и наверное даже лучше - скаффолды таких хелперов (ну уж не нам ли с макросами и "code is data" генераторы кода то писать?)

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

@nicola > Умное обновление пиши ручками в сервисной функции, можешь для этого парочку generic хэлперов написать (update-association task :subtasks) Такая функция будет выглядеть вот так?

(defn save [task]
  ;; make updates in database
  )

(defn save [id new-title new-subtasks updated-subtasks deleted-subtasks]
  ;; make updates in database
  )

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

тут проблема в том, что у меня сабтаск это часть агрегата task(в терминал domain driven design), то есть сабтаск это часть объекта task. Соответственно обновлять таск и сабтаски должна одна функция.

Попробую упростить вопрос)

Возьмем пример попроще. Есть объект task: { id: 123, title: "Buy a milk" }, бизнес правило: title не может быть пустым. Есть функция update-task которая принимает данные от пользователя:

(ns 'app.api)
(defn update-task [id title]
  (let [
    task find-task-by-id(id)
    updated-task update-title(task title)
    ]
    (save task) ;; or (save id (:title updated-task))
  )

(defn update-title [task title]
  (check-not-empty title)
  (assoc task :title title)
  )

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

update
from tasks
where task_id = 42
set title = :title

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

в смысле, зачем тебе сначала находить?

@deeper4k: update-task легко параметризуется именем таблицы и валидатором в общую функцию update

и не чистые функции по определению не функциональны

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

@nicola: > update-task легко параметризуется именем таблицы и валидатором в общую функцию update а если у меня обновление таска это не только валидация и сохранение, но и вызовы например каких-то других сервисов?

ну тогда я скорее про save говорил

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

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

@nicola: я ведь правильно понимаю, что лучше параметризовать мою чистую функцию функцией save, которая сделает грязную работу(сохранит изменения в базу)?

Если ты хочешь абстрагироваться от базы можно и подобный Dependency Injection сделать - но много писать придеться

Как извращаться для очистки функций каждый сам выбирает

Можно вместо выполнения запросов возвращать план выпролнения, эдакую IO:monad

Я обычно не заморачиваюсь

Пишешь generic набор грязных функций для работы с базой - порождения sql : update, create, delete, select etc

Всякие вещи похитрее как обновление ассоциаций, жадная загрузка тоже пишешь в общем виде

Потом в сервисных (грязных функциях) или прямо в HTTP handlers их дергаешь

спасибо, я как раз пытался выяснить есть ли готовое решение для абстракции, выходит что нет

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

базовый ORM (ala ActiveRecord || Hibernate) впринципе не сложно повторить - но будет выглядить не clojure way

а почему будет выглядеть не clojure way?

потому что много решений нужно хардкодить

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

в общем виде симулировать можно так (action metadata data)

в мета-дата ты например данными описал ассоциации

ага, понимаю

а action может прочитать эти метаданный и сделать что-нить умное

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

например (let [to-create to-remove to-update] (merge-association old new))

2/3 валидаций тоже (prismatic schema)

у нас в парочке проектов ушло вначале по недельке на написание подточенного под проблемы ala-ORM и потом постепенное эвалюционированние в разных направлениях

например метаданные о сущностях можно в стиле ActiveRecord доставать из метаданных базы или получать из swagger

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

ясно, придется свое решение пилить)

может оно и к лучшему)

jdbc & honeysql будет хорошим фундаментом

а ты используешь агрегаты в своих фп приложениях?

в одном проекте мы например расширили honeysql, чтобы он делал жадную загрузку: {:select [:*] , :from [:user], :with [:groups :settings]} - там на пол странички кода

аггрегаты? в понимании DDD?

да

да, но с ними всегда проблема

где граница?

не всегда понятно

поэтому используем, но не религиозно

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

и тоже используем не религиозно, на сотню сущностей пару агрегатов

я больше склоняюсь к use-case driven - те вычленять не структурную модель, а поведеньческую

@nicola: может соберешь гисты ассоциаций, форм билдера и что есть в репо типа howto/cookbook?

@deeper4k: раз уж тут заговорили про всякие ассоциации с sql то автор honeysql как-то пытался пилить https://github.com/jkk/cantata. не в плане “стоит использовать”, но”посмотреть"