Исправление BattleCoder, (текущая версия) :
Ну наконец-то хоть где-то моя игрушечная писанина кому-то пригодится.
Тыц https://github.com/fancywriter/car-adverts/blob/master/app/dao/CarAdvertsDao....
Тыц2 https://github.com/fancywriter/car-adverts/blob/master/app/loader/Loader.scala
везде пишешь эти db.run(query.filter(...).result), когда кажется нормальным что-то вроде query.filter(...).execute
В slick2 примерно так и было, но slick3 переписали на DBIO, чтобы каждая операция была асинхронной, поэтому запрос мало создать, надо его обернуть в db.run()...
тут вообще похоже на какой-то жаваскрипт получается. Future[Option[Future]] как сократить до Option[Future] ?
Можете обмазаться трансформерами монад, если хотите. Станет ли лучше, не уверен ;) http://typelevel.org/cats/datatypes/optiont.html
и, как я понимаю, именно здесь и понадобился нам ExecutionContext, и мы завернули в кучу Future код, который оказался блокирующим. или зачем тут ExecutionContext ?
Где вы тут увидели блокирующий код? Его нет, он весь целиком в dbio от slick. Почитайте http://docs.scala-lang.org/overviews/core/futures.html
Вообще for-comprehension - сахар на flatMap/withFilter/map/foreach. Попробуйте поэтапно переписать всё это через цепочку flatMap - в качестве упражнения, естественно. Выглядеть будет хуже и страшнее, зато вам будет понятнее, что там на самом деле происходит.
Future.map/flatMap требует ExecutionContext - в нём будут выполняться операции над результатом, который future (когда-нибудь) вернёт. Вот для этого нужен. Надеюсь, понятно объяснил...
P.S. Ещё хорошим стилем считается писать тип возвращаемого значения для public def/val. Хоть компилятор его потом и выведет, зато с типами читать легче. Да и где-то читал, что компилируется быстрее, типы выводить не надо (не замерял, не уверен).
Исходная версия BattleCoder, :
Ну наконец-то хоть где-то моя игрушечная писанина кому-то пригодится.
Тыц https://github.com/fancywriter/car-adverts/blob/master/app/dao/CarAdvertsDao....
Тыц2 https://github.com/fancywriter/car-adverts/blob/master/app/loader/Loader.scala
везде пишешь эти db.run(query.filter(...).result), когда кажется нормальным что-то вроде query.filter(...).execute
В slick2 примерно так и было, но slick3 переписали на DBIO, чтобы каждая операция была асинхронной, поэтому запрос мало создать, надо его обернуть в db.run()...
тут вообще похоже на какой-то жаваскрипт получается. Future[Option[Future]] как сократить до Option[Future] ?
Можете обмазаться трансформерами монад, если хотите. Станет ли лучше, не уверен ;) http://typelevel.org/cats/datatypes/optiont.html
и, как я понимаю, именно здесь и понадобился нам ExecutionContext, и мы завернули в кучу Future код, который оказался блокирующим. или зачем тут ExecutionContext ?
Где вы тут увидели блокирующий код? Его нет, он весь целиком в dbio от slick. Почитайте http://docs.scala-lang.org/overviews/core/futures.html
Вообще for-comprehension - сахар на flatMap/withFilter/map/foreach. Попробуйте поэтапно переписать всё это через цепочку flatMap - в качестве упражнения, естественно. Выглядеть будет хуже и страшнее, зато вам будет понятнее, что там на самом деле происходит.
Future.map/flatMap требует ExecutionContext - в нём будут выполняться операции над результатом, который future (когда-нибудь) вернёт. Вот для этого нужен. Надеюсь, понятно объяснил...