или напротив

у меня он интересно поругивается

slick имеет свойство ргуаться на id даже когда дело не в нём.

говорит что не может привести к int вторую колнку со строкой

org.postgresql.util.PSQLException: Bad value for type int : some string

Как выбрать из двух Option только то, что не пустое? В функциональном стиле?

orElse?

а если оба не пустые?

)) мда

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

можно их конечно в список загнать...и flatten сделать, так по моему...

orElse как подсказали выше не подойдет?

пойдет, спасибо)

не за что ?

не за что ?

Хорошо, напишу Мартину)

да хоть Марти МакФлаю

Не, ну этот не приложил ни одной руки к созданию Scala)

Не, ну этот не приложил ни одной руки к созданию Scala)

Ты не смотрел чтоли 4-ую часть?

Ты не смотрел чтоли 4-ую часть?

Не помню уже что там было) тем более о Скале

Не помню уже что там было) тем более о Скале

Там к Одерски попадает из будущего "альманах языков программирования". Он собственно на основе его анализа и строит скалу теперь. Только там книженция пострадала слегка, поэтому описания обрывочные и приходиться тратить много времени на эксперименты и закрытие пробелов собственными силами

Если отбросить этот факт, то Одерски ничем не примечателен и не сильно отличается от любого другого в этом чате

Сделай через паттерн матчинг)

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

Не самый удачный подход - исходить из того, что два разных обьекта никак не связанных между собой будут гарантированно связаны таким условием. Смердит и ведет к ошибкам. В этом случае либо задачку стоит свести к "выбрать из списка опшинов первый не НаН" либо использовать что-нибудь вроде Either

Не самый удачный подход - исходить из того, что два разных обьекта никак не связанных между собой будут гарантированно связаны таким условием. Смердит и ведет к ошибкам. В этом случае либо задачку стоит свести к "выбрать из списка опшинов первый не НаН" либо использовать что-нибудь вроде Either

скорее первый вариант.

во. я тоже, если подобная ситуация появляется, ищу более правильный подход

Передай вараргом опшины и найди прост первый не none

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

@dimstream какой бизнес кеис если не секрет?

@dimstream какой бизнес кеис если не секрет?

как бы так сказать...классификация сущьностей.

такую штуку как в плюсах провернуть

Почему index в конструктор не передать просто? Нужно тайпсейф?

такую штуку как в плюсах провернуть

Можно type provider на макросах сделать для Int.

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

не ходи в макро, ходи в мета

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

Посмотри это https://github.com/ThoughtWorksInc/template.scala

не ходи в макро, ходи в мета

2.12

2.12

и?)

не ходи в макро, ходи в мета

мета похоже еще долго не научится резолвить тип сразу при компиляции ((

scala@tinkoff.ru спонсирует "Разбор полётов", God.

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

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

а что ты имеешь ввиду под тем что "вложиться в скалу"?)

Вообще , сложились впечатление , что все скала пользователи СНГ здесь

а что ты имеешь ввиду под тем что "вложиться в скалу"?)

Сделать вклад в сообщество. Например, поддержать подкаст. Чем плохой вклад?

Вообще , сложились впечатление , что все скала пользователи СНГ здесь

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

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

Вообще , сложились впечатление , что все скала пользователи СНГ здесь

Нет, это не так. На работе много кто и не слышал про телеграм чатик. И про подкаст тоже.

и про монады ахахахаха =)

Нет, это не так. На работе много кто и не слышал про телеграм чатик. И про подкаст тоже.

Расскажи им ?

рассказываю :)

Вообще , сложились впечатление , что все скала пользователи СНГ здесь

И не только пользователи ?

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

@pollbot, @vote

там есть какой-то убогий бот про опросы, который всё засирает

vote вроде бы нормальный

что-то сдается мне active-slick косячит

так есть хороший tutor по slick dao с паттернами ?

Как вы используете Scala? Основная работа на ней – 55 ??????? 52% Часть работы не ней (меньше половины) – 17 ?? 16% Пока только изучаю – 17 ?? 16% Просто сижу в чатике – 10 ? 9% Пишу на ней для себя в свое удовольствие – 7 ? 7% ? 106 people voted so far.

кто-нибудь пользуется play+macwire?

А как разделить ответы "пока только изучаю" и "пишу в своё удовольствие". Имеется ввиду в своё удовольствие когда пишешь - уже всё знаешь? :)

А как разделить ответы "пока только изучаю" и "пишу в своё удовольствие". Имеется ввиду в своё удовольствие когда пишешь - уже всё знаешь? :)

это определяется субъективно.

Да, и как разделить ответы "Основная работа на ней" и "Просто сижу в чатике"? :)

Да, и как разделить ответы "Основная работа на ней" и "Просто сижу в чатике"? :)

:)

видимо это опрос на честность с самим собой

Да, и как разделить ответы "Основная работа на ней" и "Просто сижу в чатике"? :)

Ну это ж pattern matching выбирай по тем же правилам ?

у меня MatchError

последний case по идее должен у всех срабатывать

ERROR: S client not available

Только начал пробовать скалу на боевом проекте, сразу куча вопросов, подскажите сведущие: Пытаюсь сделать более менее общий метод для фильтрации в слике, то что сейчас компилируется def findBy(name: String, owner: String): Future[Option[models.Project]] = { val query = projects.filter { project => List( Option(name).map(project.name === _), Option(owner).map(project.owner === _) ).collect({ case Some(criteria) => criteria }).reduceLeftOption(_ || _).get } .take(1) db.run(query.result).map(_.headOption) }

Хотелось бы вместо аргументов получать Map со списком аргументов (ключ -> значение) и фильтровать по ним, но у класса нет динамического дотупа к полям project.get(keyName) или я не нашел его :)

Возможно ли сделать так на скале? и есть ли что-то антипаттерное в коде выше

Только начал пробовать скалу на боевом проекте, сразу куча вопросов, подскажите сведущие: Пытаюсь сделать более менее общий метод для фильтрации в слике, то что сейчас компилируется def findBy(name: String, owner: String): Future[Option[models.Project]] = { val query = projects.filter { project => List( Option(name).map(project.name === _), Option(owner).map(project.owner === _) ).collect({ case Some(criteria) => criteria }).reduceLeftOption(_ || _).get } .take(1) db.run(query.result).map(_.headOption) }

выкинь это гавно нахер и возьми doobie )

а во что это превращается в sql-е?

выкинь это гавно нахер и возьми doobie )

Не ругайся

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

Option(name) это точно не нужно (согласно здравого смысла, про слик хз)

List(Option("foo"), Option("bar")).collect({case Some(baz) => baz}) можно записать как List(Option("foo"), Option("bar")).flatten

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

Этих условий много будет? Для двух явно избыточно делать список и потом сворачивать

Не ругайся

прости батюшка, бес попутал

Только начал пробовать скалу на боевом проекте, сразу куча вопросов, подскажите сведущие: Пытаюсь сделать более менее общий метод для фильтрации в слике, то что сейчас компилируется def findBy(name: String, owner: String): Future[Option[models.Project]] = { val query = projects.filter { project => List( Option(name).map(project.name === _), Option(owner).map(project.owner === _) ).collect({ case Some(criteria) => criteria }).reduceLeftOption(_ || _).get } .take(1) db.run(query.result).map(_.headOption) }

Касательно критериев, как ключ -> значение. На сколько я понимаю models.Project это обычный case class. Естественно у него нет функции get. Здесь стоит смотреть либо в рефлексию, как в джае и искать через нее геттер. Либо использлваться shapeless.

конкретно в запросе project это сликовое олицетворение одного ряда там потому и операторы сравнения свои, а не стандартные ==

Только начал пробовать скалу на боевом проекте, сразу куча вопросов, подскажите сведущие: Пытаюсь сделать более менее общий метод для фильтрации в слике, то что сейчас компилируется def findBy(name: String, owner: String): Future[Option[models.Project]] = { val query = projects.filter { project => List( Option(name).map(project.name === _), Option(owner).map(project.owner === _) ).collect({ case Some(criteria) => criteria }).reduceLeftOption(_ || _).get } .take(1) db.run(query.result).map(_.headOption) }

Будет что-то вроде val projectGen = LabelledGeneric[model.Project] def findBy(criteria: (Symbol, String)*): Future[Option[models.Project]] = { val query = projects find { project => val rec = projectGen.to(project) criteria contains { case (key, value) => rec(key) === value } } db.run(query.result) } Не уверен что будет работать. Шеплес строгал последний раз года 2 назад, а слик и того больше.

да критериев полно, здесь для примера только 2 список критириев со значениями будет приходить из формы с клиента и хотелось использую названия критериев фильтровать нужные значения

да я как раз прочитал про case class у которых нет getter и на этом застопорился

за основу брал пример с документации http://slick.lightbend.com/doc/3.0.0/queries.html#sorting-and-filtering по почему то Column[Boolean] у меня не согласуется с тем что ожидает slick кажется slick.Rep[_]

Будет что-то вроде val projectGen = LabelledGeneric[model.Project] def findBy(criteria: (Symbol, String)*): Future[Option[models.Project]] = { val query = projects find { project => val rec = projectGen.to(project) criteria contains { case (key, value) => rec(key) === value } } db.run(query.result) } Не уверен что будет работать. Шеплес строгал последний раз года 2 назад, а слик и того больше.

спасибо попробую :) пойду читать документацию shapeless

True story https://twitter.com/milessabin/status/841219815658393600

Минус такого подхода в том, что если будет опечатка в критерии, программа свалится в рантайме, что не есть гут

Дано: sbt, 3 модуля (задефайнены через lazy val project_name = project.settings...). Выполняем: sbt publishM2. Что происходит : сбт паблишит 4 проекта (общий(пустой, без включения модулей) и по одному на каждый модуль) Вопрос: можно ли сбт сказать, чтобы вместо 4-х паблишил 1 - сборную солянку?

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

Дано: sbt, 3 модуля (задефайнены через lazy val project_name = project.settings...). Выполняем: sbt publishM2. Что происходит : сбт паблишит 4 проекта (общий(пустой, без включения модулей) и по одному на каждый модуль) Вопрос: можно ли сбт сказать, чтобы вместо 4-х паблишил 1 - сборную солянку?

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

Эволюция адоптера

а у нас кто-нибудь doobie юзает?

есть

Явные проблемы есть?

выкинь это гавно нахер и возьми doobie )

выкинь это гавно нахер и возьми doobie )

?

слик прям плох? или это утрированная версия утвеждения)