SORM. Новый элегантный и масштабируемый ORM фреймворк для Scala

[SuDDeN]

Выглядит любопытно, надо попробовать. Ну и с первый постом что-ли :)

[mojojojo]

Спасибо!

[dayman]

Не только с постом, но, похоже, и с фреймворком!) Вы автор?

[dayman]

А все, понял, прошу прощения. Ниже вы писали о том, что вы его разработчик, а не разработчик на нём)

[mojojojo]

Спасибо. Да, автор.

[max_m]

а в чем заключается масштабируемость данного фреймвокра?

[mojojojo]

На данный момент это встроенный connection pooling. Вот всё, что нужно изменить в примере, для того, чтобы программа поддерживала 16 соединений к БД:

object Db extends Instance (
  entities = Set() + Entity[Artist]() + Entity[Genre](),
  url = "jdbc:h2:mem:test",
  poolSize = 16 // <--
)

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

[Evengard]

Вы разработчик? Как с Akka будет работать?

[mojojojo]

Я разработчик. С Akka работает без проблем. Проверено на собственных проектах.

[Evengard]

Короткий пример с Akka можете показать?

[mojojojo]

Объект Db Вам доступен из любого контекста в Вашем приложении, что освобождает от какой-либо специфики в работе с актёрами.

Вот кусок кода из одного моего приложения:

class DbNegotiator extends Actor {
  def receive = {
    case CreateTasks(asins) =>
      Db.transaction {
        val existingTasks = Db.query[Task].whereIn("asin", asins).fetch().toStream
        // reset the failed generated ones
        existingTasks
          .filter(_.failure != None)
          .filter(_.generated)
          .map(_.copy(failure = None, generated = false, outdated = false))
          .foreach(Db.save)
        // create the new ones
        asins.view
          .diff(existingTasks.map(_.asin))
          .foreach(a => Db.save(Task(_, Db.now())))
      }
  }
}

[dayman]

Как-то просто все, где-то подвох:)

[mojojojo]

Всё дело в том, что первым этапом в разработке данного фреймворка решался вопрос, того, как он будет использоваться, и уже под это писалась вся подноготная. В этом, мне кажется, и заключается его принципиальное отличие от таких библиотек, как Squeryl или Slick, в которых фичи появлялись по ходу разработки, а вопрос гармоничности АПИ был совершенно второстепенным.

[Throwable]

> whereEqual(«genres.item.name», «Rock»)
Ссылаться на поля строковыми параметрами как-то противоречит идеологии typesafe.

Есть фреймворк QueryDsl. Это не ORM, но надстройка над ним для typesafe запросов. ORM-backend-ом может являться все что угодно — JPA/JDO/MongoDB/SQL. Изначально сделан под Java, но есть порт под Scala: blog.mysema.com/2010/09/querying-with-scala.html

[mojojojo]

Да, противоречит, но:
1. Далеко не всякое typesafe решение оказывается удобнее. Во многих случаях в жертву приносится функциональность и лаконичность.
2. Не стоит преувеличивать возможности typesafe. Это, всего лишь, статическая проверка типов. Она не спасает от массы рантайм-ошибок другого происхождения, из-за чего, как ни крути, приложение надо-таки тестировать.
3. Как то же живут люди с питонами, руби и т.д. Да, мало того, что живут, порой динамику и в культ возводят.

Однако, как бы то ни было, сейчас идёт работа по интеграции макросов, на которых будет основано новое статическое АПИ для запросов, благодаря чему и данный вопрос будет исчерпан.

[Frenzy]

Над чем абстракция? Над JDBC обычным, я так понимаю? Т.е. все запросы блокирующие/синхронные? Вы там выше пример с Аккой природите, правильно ли я понимаю, что thread блокируется в момент, когда вы делаете fetch (ну или последующую операцию на его результате) и это всё не reactive? Если да, то говорить, что это «работает» с Аккой всё-таки не совсем честно ;)

[mojojojo]

1. Если Вы знаете лучший способ коннектиться к Postgre или Mysql из JVM, чем «JDBC обычный», уж, пожалуйста, поделитесь. Ладно лучший — хотя бы даже иной.

2. Запросы блокирут тот тред, на котором запущены. Естесственно. 2+2 тоже блокирует тот тред, на котором вычисляется. Объявление future тоже блокирует тред на момент объявления и выделения треда для вложенных вычислений. Любая вычислительная операция неизбежно блокирует тот тред, на котором исполняется при любой модели программирования. Главное, что SORM не блокирует обращения к БД, сделанные с разных тредов, благодаря пулингу соединений, чего, к примеру, лишён Slick.

3. Если то, в чём Вы пытаетесь упрекнуть — это отсутствие асинхронности, то да, в библиотеке её нет. Впрочем, и реализовывать её было бы глупо, т.к. вот всё, что требуется для того, чтобы в Scala сделать операцию асинхронной:

// sync:
val artists = Db.query[Artist].fetch()
// async:
future{ Db.query[Artist].fetch() }.foreach{ artists => ... }

4. Мне кажется, у Вас ошибочное представление о модели актёров. Суть в том, что она сама и является абстракцией над многопоточностью. Альтернативный Future подход к асинхронным вычислениям. Так, в приложении, из которого я приводил пример, параллельно работает 16 инстансов такого актёра, и никто не мешает изменить их количество на, скажем, 1000, однако встаёт вопрос разумности.

Поэтому, да, SORM работает с Akka, без всяких увиливаний.

[Frenzy]

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

Т.е. вы правда даже представить себе не можете других вариантов как можно было бы работать с реляционной БД вроде PostgreSQL/MySQL не будь у вас JDBC с драйверами от вендоров? Для вас так естественно, что «запрос» (обычная сетевая операция ввода вывода, ожидающая ответа от удалённого сервера) блокирует поток? Акка с блокирующими акторами – это примерно как забивание гвоздей микроскопом, поверьте, она вам на самом деле нафиг не нужна. Вы просто мелко плаваете и о высокой нагрузке и масштабировании имеете очень отдалённое представление, поэтому вы смотрите на всё зашореным взглядом и пишете 100500-й никому не нужный ОРМ-велосипед, в то время как простаивают серьёзные задачи, за решение которых коммьюнити действительно сказало бы вам спасибо.

[Evengard]

Посоветуйте плз альтернативу для использования с Аккой

[mojojojo]

Раз Вы считаете, что конструктивная дискуссия начинается с претенциозной критики, которую Вы даже не пытаетесь обосновать, и перетекает в непосредственные оскорбления, на этом я её прекращу.

[Frenzy]

Т.е. вы считаете, что когда я сказал «не совсем честно» – это было «претенциозно», а когда вы в ответ на это (вполне кстати конструктивное) замечание сказали, что я вобще не понимаю, что такое Акка, и вобще ерунду какую-то несу – это вот нормально.