Squeryl — простота и изящество

[aparamonov]

Мне не понравился подход, который используется для описания сущностей — изменяемые структуры, какой-то лишний trait на сущность.
Я считаю более удачный подход, который используется в slick — case classes, описание структуры таблицы отдельно от сущности. Это проще для восприятия и лишено side effects, так как возможно использование модели где угодно.

Еще Ваше решение ну очень слабо тестируемо, так как package object models не замокаешь.

[a696385]

В Squeryl также можно использовать case classes. На счет описания, а вот вы попробуйте в рантайме получить список таблиц с алиасами и хотя бы список полей с типами и алиасами. А задача банальна — дать возможность через API получать только нужные поля и устанавливать любые фильтры на эти поля. В JPA это очень просто, в Squeryl это чуточку сложнее, в Slick это костыли

[SpeakerRed]

Если даже не касаться вопроса тестирования, то тот package object, кхм… попахивает.

[a696385]

Главным на мой взгляд недостатком является отсутствие механизма миграций, максимум что может сделать Squeryl, так это выдать текущий DDL.

Разработчик библиотеки писал по этому поводу уже, и мне кажется он полностью прав. Для этой задачи есть специализированные библиотеки, которые прекрасно справляются со своей задачей
https://groups.google.com/forum/#!searchin/squeryl/migration/squeryl/m9ruq6Z1j7A/N_9pxwF-kkUJ

[dougrinch]

Где-то полгода назад отказался от использования squeryl. В нем очень не хватает возможности писать sql руками.

[voronaam]

Сильно не хватает, особенно с учётом того, что она там есть :) Вот, например, вариант: gist.github.com/max-l/9250053

Вообще Squeryl удивительно логичен внутри. Его можно расширять и видоизменять под любой вариант, практически. Первый ORM, с которым я не чувствую себя ограниченным.

[lucky_libora]

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

[dougrinch]

О, спасибо огромное. Я этот способ не смог найти/придумать.

Однако, не покидает ощущение костыльности происходящего. Да и в любом случае, 75 строчек вспомогательного кода ради данного функционала явный перебор. Хочется «просто взять, и выполнить запрос».

[lucky_libora]

костыльности, как таковой и нет, скорее это просто дополнение для расширения функционала squeryl

[eld0727]

Что то я не смог понять что вам мешает писать на простом jdbc внутри транзакции, если уж так надо писать «sql руками»?