Помнится, на первом скала-митапе при разговоре про Slick кто-то упоминал, что там очень трудно работать с SQL-запросами, если надо в зависимости от условий "собрать" запрос из нескольких кусков. Вроде, вот этот снипет позволяет конкатенировать sql"" макросы как угодно: https://gist.github.com/gmanny/c05b25b6192fb1212175331a4fc14c65

А зачем нужно собирать запросы из кусков? Почему бы не описать то же в виде какой-нибудь своей структуры данных и собирать из нее запрос в самом конце?

Так или иначе, чтобы собрать запрос иногда нужно полключать и отключать куски внутри которых есть параметры sql"blablabla $parameter blablabla", чтобы слик правильно подставил ? и транслировал параметры отдельно.

в scalikejdbc так давно и очень удобно строить запросы

В scalikejdbc результат нельзя принять простым .as[(Long, Double, Seq[String], Option[String], DateTime)], надо работать с резалтсетами, это больше кода, дольше писать, труднее поддерживать.

Яснопонятно Свой тип данных всяко удобнее комбинировать, чем клеить строки Хотя бы чтобы избежать островков stringly-typed кода

А подскажите в liftjson есть вариант целый JValue конвертнуть в Map[String, String]?

http://fasterj.com/tools/gcloganalysers.shtml недавно тут говорили об этом

http://gceasy.io/

и вот еще

Что не так со склеикой строк

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

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

не то чтобы это была неразрешимая задача...

но

Где-то я недавно видел спор на rsdn про склейку строк vs linq

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

так чтобы универсально

Короче, правильно написанный LinqProvider(типа Linq2DB) генерит запросы, очень близкие к оптимальным

Другой вопрос - прокладка между стулом и монитором

Никогда не было понятно зачем класть монитор на стул

Я к тому, что linq, как и любой другой инструмент, не делает магии

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

Это скорее вопрос вкуса

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

Slick нет :D

Slick нет :D

так там было сказано “правильный” ?

Если я правильно понял их док, то у них вообще позиция "индексы? ключи? мы вам слепим гуано из подзапросов и валяйтесь с ними как хотите"

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

Базы банных в 2016 когда все можно уместить в память. No way.

всё в уме держишь? мужик!

Бд нужны только чтобы персистить туда ивенты.

А то!

Бд нужны только чтобы персистить туда ивенты.

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

ну ок, пойду всем расскажу

Бд нужны только чтобы персистить туда ивенты.

+1

Нет ничего кроме эвента, и все события -- эвенты его

и все события последствия его

Че

Мы сложные запросы в базе держали ? Поддерживать относительно легко.

Ужс

А куски верстки у вас случаем в бд не лежали?

так вроде же какие то движки прям все держат в бд

Нормально работает) ибо нех юзать динамику

так вроде же какие то движки прям все держат в бд

Я знаю, и это жесть.

А куски верстки у вас случаем в бд не лежали?

Код автогенеренных форм да лежит. Вот такой у нас движок. Апдейт идет одним дампом БД ?

так вроде же какие то движки прям все держат в бд

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

Ну можно для фильтров и одну кверю написать?

А пагинация вообще не проблема

Зато он закешируется)

слушайт

е

тут такая тема всплыла

вот кодишь ты такой свой проект, думаешь стрелки клейсли внедрить и клево сделать, а тебе не ревью говорят что НЕЛЬЗЯ СУКА С ИЗ СОЛИДА НАРУШАТЬ. бывало так?

Что такое солид?

SOLID же

@Emiya402 это на самом деле самый крутой ответ

SRP, Open/Close, LSP, interface segregation, deps inversion

или я сарказм не разглядел? :)

ERROR: S client not available

=(((

тогда +1 за ответ

а как там SRP нарушается? Можно подробнее?

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

есть вообщем сущность

есть класс обработчик который парсит из текста сущность

есть класс аналайзер который допинфо дергает и делает из сырой сущности сущность

Блин, я правда в 8 30 утра не вспомнил бы про паттерны.

на вопрос нахуй мы 30 мультов сущностей по два раза гоняем и не перетащить ли логику аналайзера в парсер мне указали на СРП

класс-обработчик вытаскивает сырую сущность?

при этом класс аналайзера создается фэктори методом вообще из другого подпроекта и включает в себя 3-4 класса стратегии

да

бля жесть. фактори метод а-ля джава стайл?

да

причем метод в объекте в абсолютно другом подпроекте

и люди глядя на это мне говорят что это СОЛИД и я подумал наверное рановато я про клейсли задумался

имхо SRP не нарушен. Один класс занимается text->raw. Другой класс занимается raw->entity. Ну захотел, сделал функцию text->entity, в чем проблема :)

это происходит так

читаем текстовый файл спарком парсим в raw

сериализуем на hdfs

читаем

Там в паттернах есть interpretator pattern - скажи что его юзаешь. Его все равно не понять и под ним можно паосеры, адт и прочее в проект под видом "а оно есть у генг оф 4" пропихнуть .

анализируем в entity

так надо фэктори сделать, чтобы из парсера и клейсли билдеры собирала ?

уж на такие паттерны ООПшники грешить не станут

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

Это тоже хороший совет!

кстати да )