Комментарии 10
Мне не понравился подход, который используется для описания сущностей — изменяемые структуры, какой-то лишний trait на сущность.
Я считаю более удачный подход, который используется в slick — case classes, описание структуры таблицы отдельно от сущности. Это проще для восприятия и лишено side effects, так как возможно использование модели где угодно.
Еще Ваше решение ну очень слабо тестируемо, так как package object models не замокаешь.
Я считаю более удачный подход, который используется в slick — case classes, описание структуры таблицы отдельно от сущности. Это проще для восприятия и лишено side effects, так как возможно использование модели где угодно.
Еще Ваше решение ну очень слабо тестируемо, так как package object models не замокаешь.
В Squeryl также можно использовать case classes. На счет описания, а вот вы попробуйте в рантайме получить список таблиц с алиасами и хотя бы список полей с типами и алиасами. А задача банальна — дать возможность через API получать только нужные поля и устанавливать любые фильтры на эти поля. В JPA это очень просто, в Squeryl это чуточку сложнее, в Slick это костыли
Если даже не касаться вопроса тестирования, то тот package object, кхм… попахивает.
Главным на мой взгляд недостатком является отсутствие механизма миграций, максимум что может сделать Squeryl, так это выдать текущий DDL.
Разработчик библиотеки писал по этому поводу уже, и мне кажется он полностью прав. Для этой задачи есть специализированные библиотеки, которые прекрасно справляются со своей задачей
https://groups.google.com/forum/#!searchin/squeryl/migration/squeryl/m9ruq6Z1j7A/N_9pxwF-kkUJ
Где-то полгода назад отказался от использования squeryl. В нем очень не хватает возможности писать sql руками.
Сильно не хватает, особенно с учётом того, что она там есть :) Вот, например, вариант: gist.github.com/max-l/9250053
Вообще Squeryl удивительно логичен внутри. Его можно расширять и видоизменять под любой вариант, практически. Первый ORM, с которым я не чувствую себя ограниченным.
Вообще Squeryl удивительно логичен внутри. Его можно расширять и видоизменять под любой вариант, практически. Первый ORM, с которым я не чувствую себя ограниченным.
спасибо за пример, хотя у меня не было необходимости писать SQL руками, думаю пригодится
О, спасибо огромное. Я этот способ не смог найти/придумать.
Однако, не покидает ощущение костыльности происходящего. Да и в любом случае, 75 строчек вспомогательного кода ради данного функционала явный перебор. Хочется «просто взять, и выполнить запрос».
Однако, не покидает ощущение костыльности происходящего. Да и в любом случае, 75 строчек вспомогательного кода ради данного функционала явный перебор. Хочется «просто взять, и выполнить запрос».
Что то я не смог понять что вам мешает писать на простом jdbc внутри транзакции, если уж так надо писать «sql руками»?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Squeryl — простота и изящество