Принуждение фасоли Scala :: Пропавшее LINQ - PullRequest
Новая
       4

Принуждение фасоли Scala :: Пропавшее LINQ

1 голос
/ 25 ноября 2011

Обновление

Версия Play 2.0 для Scala будет содержать ANORM , что похоже на Querulous в том смысле, что оба являются JDBC-обертками, а не ORM. Вот приведение запроса ANORM при работе с комбинатором синтаксического анализа: 

SQL("""
        select * from Country c 
        join CountryLanguage l on l.CountryCode = c.Code 
        where c.code = 'FRA';
    """
    ).as(
        str("name") ~< spanM(
            by=str("code"), str("language") ~< str("isOfficial") 
        ) ^^ { 
            case country~languages => 
                SpokenLanguages(
                    country,
                    languages.collect { case lang~"T" => lang } headOption,
                    languages.collect { case lang~"F" => lang }
                )
        } ?
    )

Многострочный запрос "" "sql" "" хорош, мне это нравится, но приведение, пожалуйста, нет ;-) В Groovy приведение bean-компонентов к одному и тому же запросу является 1-строчным: 

List[Country] c = sql.rows("select * from country")?.collect{ it.toRowResult() as Country }

Нулевой безопасный оператор (? .Might-be-null) в groovy довольно удобен, для scala, похоже, требуется комбо Some () Option [] для обработки возможных нулевых результатов. Нравится ли кодировщикам Scala нулевая обработка в Scala?

Полагаю, что основной смысл этого поста таков: может ли Scala обеспечить краткость языка сценариев при сохранении безопасного кода типа компилятора? Учитывая, что Scala, возможно, более мощный / выразительный, чем C # (непреднамеренное пламя), тогда полноценный Scala LINQ должен быть возможен. Кроме того, поскольку Scala охватывает функциональную и ОО-парадигмы, он также должен быть в состоянии достичь краткости на уровне Groovy (например, приведенное выше 1-линейное приведение бина запроса).

Если эти предположения верны, то почему для существующих scala ORM и оболочек jdbc требуется так много стандартного шаблона по сравнению с groovy и LINQ на C #? Очевидно, я идеалист, ищущий простые DSL, в которых реализации либо невероятно лаконичны, либо близко отражают базовый язык, который они представляют (как в LINQ-to-SQL).

Оригинал

Пробежался через различные ORM Scala (squeryl, daomapper, пара других, которые будут заполнены позже) и вспомогательные среды SQL (пока что))

Будучи новичком в Scala и строго типизированных языках в целом, одна вещь, которая бросается в глаза - это необходимость указывать тип (String, Int и т. Д.) Каждого столбца в каждом результате запроса.

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

На данный момент, быстрый из readme Querulous на github: 

val users = queryEvaluator.select("SELECT * FROM users WHERE id IN (?) OR name = ?", List(1,2,3), "Jacques") { row =>
  new User(row.getInt("id"), row.getString("name"))
}

Хотя я понимаю, что компилятору нужно знать тип каждого «объекта», с которым вы работаете, кажется, что не DRY должен указывать «row.getInt ('id')», когда сам класс домена уже объявляет, что Идентификатор имеет тип Int.

Итак, исходя из значительной степени незнания, я спрошу, почему платформы ORM и вспомогательные средства SQL Scala не предоставляют разработчикам модель реализации, которая допускает предполагаемые или неявные наборы результатов?

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

1 Ответ

4 голосов
/ 25 ноября 2011

См. Интегрированный запрос Scala , насколько я понимаю, он запланирован для интеграции в типобезопасный стек в виде интегрированного комплекта языка Scala ( SLICK )

enter image description here

...