Pull to refresh

Comments 17

Спасибо за материал. Очень его не хватает по Slick.

>и дождёмся её выполнения с помощью Await.result(databaseFuture, 1 second)

Пометьте пожалуйста, что это только для примера. И в реальном проекте это плохая практика.
А то мне приходилось работать с проектом, где из асинхронного Slick, делали синхронный при помощи Await.result.
Люди на столько привыкли к хиберу, что не могли понять, как можно с БД работать асинхронно.
Спасибо! Отметил.
Действительно, асинхронные интерфейсы требуют тектонических сдвигов в голове.
> фамилия одной из величайших солисток всех времён
Не выдумывайте.
А по-моему, это вполне естественно использовать for для итерации по строчкам таблиц реляционных баз данных. Тем более есть отличная аналогия со списками.
В том-то и дело, что for используется не для итерации по строчкам базы данных, а для композиции метаданных, т.е. классов, описывающих таблицы. На момент формирования запроса мы ещё не обращаемся к базе, а только лишь формируем SQL-строку.

Так нет же никакой разницы, выполнится запрос сразу или чуть позже. Конечно, итерация происходит не на Scala коде, а в базе.

Да, в этом мощь абстракции Slick, можно якобы вообще забыть про SQL и представлять, будто этот код выполняется прямо на базе данных. Но это ровно до первой ошибки :) Причём в случае со Slick это будет ошибка компиляции, в содержание которой очень сложно вникнуть, если не понимаешь того, как именно этот код преобразуется в SQL.
Справедливости ради «можно якобы вообще забыть про SQL» это девиз всех средств абстрагирования от БД.
Будь то ОРМ или FRM или еще что.
Но в Slick, на самом деле не сложно разобраться.
Главное не делать сразу большие глаза и не кричать с порога «сложнааааааа», как это любят делать многие.
Поняв основные принципы проблем потом практически не возникает.
Как написать SQL-запрос на Slick и не быть уволеным никогда из этой фирмы больше
Ну зря вы так :) Для того я и написал эту статью, чтобы поделиться опытом и помочь другим разобраться.
У вас (компании) классные иллюстрации! Думал сайт оформлен подобным образом, оказалось нет.
Тоже долго разбирался со Slick, но когда разобрался, оказалось так быстро и легко работать с ним с базами данных.
Спасибо за статью. Тоже в свое время похожим образом проходило мое знакомство со Slick.
Не так давно наткнулся на альтернативу — Quill (getquill.io). По ощущением от знакомства с технологией в рамках одного вечера — концепция похожая, но проще. Особенно понравилось то, что при компиляции получаем мессейджы о том, какой запрос у нас в итоге сбилдился. Думаю, для простых проектов подойдет лучше чем Slick.
Интересно, посмотрю на неё. Спасибо!

Вот мне только одно в слике не понятно: зачем он нужен, если он не умеет отображать х-to-many на case-классы? (я имею в виду случай, когда полем case-класса является список)


Или может это я что-то не так делаю?

Да, в Slick нельзя так сделать, потому что Slick — это не ORM. Он значительно ближе к реляционной модели, чем ORM. Slick не отображает внешние ключи в ассоциации, для него один кейс-класс — это одна таблица.

С маппингом ассоциаций сразу возникает целая вереница типичных проблем ORM, с которыми они справляются с весьма неоднозначными результатами, типа навигации по графу объектов, «N+1 select problem», eager/lazy fetches и т.д. В отличие от ORM, Slick даёт больше прозрачности в том, когда и какие запросы он выполняет.

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

Эхх… Видимо нет для скалы внятного способа использовать бд и иммутабельные кейс-классы :(

Sign up to leave a comment.