фух

слик неплох

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

Ну твое решение нормальное вполне, хоть и попахиват. def findBy(name: String = null, owner: String = null): Future[Option[models.Project]] = { val query = projects find { project => Seq( Option(name).map(project.name === _), Option(owner).map(project.owner === _) ) foldLeft(false) { case (acc, Some(res)) => acc || res case (acc, None) => acc } } db.run(query.result) } Наверно есдиственный случай, когда использование null оправдано. В принципе такие вещи можно макросами генерить. Тогда вообще норм.

В слике очень плохо с наборными фильтрами

Lifted запрос с опциональными фильтрами невозможно читать, а Plain не композируется

мде

переизобрел active-slick

ошибки в тех же местах

видимо это косяк org.postgresql

Oleg правда я и в doobie уже вляпался в неочень красивый batchupdate

Oleg правда я и в doobie уже вляпался в неочень красивый batchupdate

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

точно, забыл ж

и акку

java и сюда свои кривые ручонки дотянула

val projectGen = LabelledGeneric[ProjectDAO.this.dbTables.ProjectTable] def findBy234(criteria: (Symbol, String)*): Future[Option[models.Project]] = { val query = projects.filter { project => val rec = projectGen.to(project) criteria contains { case (key, value) => rec(key) === value // ^^^ - error: Application does not take parameters } } db.run(query.result) } тут что-то базовое видимо

ух. он небось только в компайлтайме доступен.

rec(key) === value вот это не скомпилится

позабыл я шеплес, да.

key здесь чистый Symbol, а нужен синглтон

val currentPrice = rec('price) price - здесь синглтон?

да

там имплицитная конверсия в Witness.Lt

позабыл я шеплес, да.

еще б идея умела с ним работать полностью

т.е. тебе нужно на этапе компиляции доказать, что любой символ из твоего Seq[(Symbol, String)] является полем твоего рекорда, что, как мне видится, невозможно

то есть получается - что это впринципе невозможно

возможно в принципе

динамически фильтровать таблицу?

дааа, просто так не заедешь в скалу)

динамически фильтровать таблицу?

плюс, я насколько помню в слике же столбцы простыми def ами у класса, а не полями case class т.е. всё упадёт ещё тогда, когда не найдётся LabelledGeneric

ага def owner = column[String]("owner")

не знаю насколько адекватное решение, но работает def findBy(criteria: (String, String)*) = db.run { projects .filter(project => criteria.foldLeft(LiteralColumn(false).bind) { case (query, (k, v)) => query && (project .column[String](k) === v) }) .result }

findBy("name" -> "project", "owner" -> "vasya")

LabelledGeneric по дефолту не ищет такое, нужно свой материалайзер писать

как код зеленым цветом отправлять? или он только для меня зеленый

в ` таких штуках

у меня красный

как код зеленым цветом отправлять? или он только для меня зеленый

тройной бэкквот

в ` таких штуках

Добро пожаловать в телеграм

как в markdown

Вот в таких ```

Там как-то все плохо с этим. Но решение есть. val unusedRepo = Some(Resolver.file("Unused transient repository", file("target/unusedrepo"))) val dontPublishSettings = Seq( publish := {}, publishTo := unusedRepo, publishArtifact := false ) У всех проектов которые не надо папблишить надо прописать .settings(dontPublishSettings:_*)

как все печально. но меня интересует не столько запрет копирования, сколько импорт сразу всех модулей в другом проекте за счет одного центрального. собственно сделал в дефолтмодуле dependsOn(mod0, mod1, mod...) - оно собирает пом который надо, с депенденсями указанными, но что-то в новом проекте не резолвит эти депенденси - странно

test

точно :)

не знаю насколько адекватное решение, но работает def findBy(criteria: (String, String)*) = db.run { projects .filter(project => criteria.foldLeft(LiteralColumn(false).bind) { case (query, (k, v)) => query && (project .column[String](k) === v) }) .result }

сейчас попробую

боюсь на не строковых колонках оно упадет в рантайме

у нас пишут все фильтры ручками

особой боли не испытываем

о

скомпилилось

спасибо

@fomkin а ты шеиплесс то юзаешь в своих проектах?

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

@fomkin а ты шеиплесс то юзаешь в своих проектах?

Пару лет уже не юзаю. Только @@.

Ну твое решение нормальное вполне, хоть и попахиват. def findBy(name: String = null, owner: String = null): Future[Option[models.Project]] = { val query = projects find { project => Seq( Option(name).map(project.name === _), Option(owner).map(project.owner === _) ) foldLeft(false) { case (acc, Some(res)) => acc || res case (acc, None) => acc } } db.run(query.result) } Наверно есдиственный случай, когда использование null оправдано. В принципе такие вещи можно макросами генерить. Тогда вообще норм.

а зачем здесь Null в дефолтах?

а зачем здесь Null в дефолтах?

прост

А у scalatest fixtures насколько глобальны?

а зачем здесь Null в дефолтах?

Чтоб можно было искать только по одному из параметров, например

https://twitter.com/contrarivariant/status/841406364891119617

https://github.com/scala/scala/pull/5774 круто если это будет в 2.12

https://github.com/scala/scala/pull/5774 круто если это будет в 2.12

Не плохо.

Не плохо.

да же очень

https://twitter.com/scaladays/status/841293753260339203

да же очень

Это жёстче CoC'а

Не плохо.

Запятая забыта? ))

был ли у кого опыт использования http://async-io.org/? точнее кластеризации этой штуки или может быть добрые люди посоветуют что-то для поддержки множества WS соединений с fallback и кластеризацией, т.к. придется держать в одним момент времени 100к+ сокетов

https://github.com/Atmosphere/atmosphere про вот это речь

ERROR: S client not available

как идиоматично в akka-streams делать периодическое(по времени или количеству элементов) логирование? Мутабельный GraphStage с счетчиком и таймером? или как-то иначе?

собрать из стандартных компонентов

собрать из стандартных компонентов

дорисуйте остаток совы

как идиоматично в akka-streams делать периодическое(по времени или количеству элементов) логирование? Мутабельный GraphStage с счетчиком и таймером? или как-то иначе?

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

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

ну да, это и есть мутабельный GraphStage с счетчиком и таймером. почему нет смысла в случае с таймером?

http://doc.akka.io/docs/akka/2.4.17/scala/stream/stages-overview.html#groupedWithin

+ http://doc.akka.io/docs/akka/2.4.17/scala/stream/stages-overview.html#log

ну да, это и есть мутабельный GraphStage с счетчиком и таймером. почему нет смысла в случае с таймером?

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

а, логирование по таймеру не стоит - ты про это?

в одном stage

в одном stage

да, про таймер. но побочный таймер не влияющий на сам ран стрима я бы вобще не вставлял в стейджи

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

в таком случае куда?

GraphStage все еще описывается кучей бойлерплейта же? Тогда отсылка в независимый актор-счетчик куда более простое решение

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

GraphStage все еще описывается кучей бойлерплейта же? Тогда отсылка в независимый актор-счетчик куда более простое решение

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

А мы все проигнорировали меня?

А мы все проигнорировали меня?

то, что ты скинул - не соответствует тому, что он описал в хотелках

то, что ты скинул - не соответствует тому, что он описал в хотелках

конкретнее

чему не соответствует?

тому, что он описал в хотелках, видимо

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

ну мы же про случай с какой то агрегацией по времени говорим?

тому, что он описал в хотелках, видимо

спс

если не хотите хранить Seq, можно использовать batch

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

ну мы же про случай с какой то агрегацией по времени говорим?

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

если не хотите хранить Seq, можно использовать batch

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

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

именно эту работу и делает groupedWithin

groupedWithin затормозит стоим, не?

Дык если речь только про метрики можно map{ x => meter.mark(); x} просто делать)

именно эту работу и делает groupedWithin

"Chunk up the stream into groups of elements received within a time window, or limited by the given number of elements, whichever happens first." - это влияет на водопад

groupedWithin затормозит стоим, не?

c какой стати?