Наткнулся тут на статью по этому поводу.
Кто что думает по этому поводу?
А там есть упоминание вот этого.

Здравствуйте, Аноним, Вы писали:

А>Наткнулся тут на статью по этому поводу.
А>Кто что думает по этому поводу?
А>А там есть упоминание вот этого.
Ну, я думаю, что лямбды это один уверенный шаг к тому чтобы отказаться от запросов и свойств в виде строковых литералов. HQL в строках сильно напрягает, но зачастую он сильно проще чем Criteria API. Да и сам Criteria API с вездесущими именами свойств напрягает. Аналог QueryDSL/Criteria API на лямбдах был бы очень кстати.
Даже в тех же JavaBeans к свойствам надо обращатся через строку-литерал. Для меня на данный момент это один из самых нелюбимых аспектов в Java.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

А>>Наткнулся тут на статью по этому поводу.
А>>Кто что думает по этому поводу?
А>>А там есть упоминание вот этого.
B>Ну, я думаю, что лямбды это один уверенный шаг к тому чтобы отказаться от запросов и свойств в виде строковых литералов. HQL в строках сильно напрягает, но зачастую он сильно проще чем Criteria API. Да и сам Criteria API с вездесущими именами свойств напрягает. Аналог QueryDSL/Criteria API на лямбдах был бы очень кстати.
B>Даже в тех же JavaBeans к свойствам надо обращатся через строку-литерал. Для меня на данный момент это один из самых нелюбимых аспектов в Java.

LINQ (если говорить про его применение в SQL) чуть-чуть о другом. Он умеет по Ява коду сгенерировать SQL код. Лямбды в Ява8 даже рядом такого не позволят сделать.

B>Аналог QueryDSL/Criteria API на лямбдах был бы очень кстати.

Это уже LINQ получится. Но я не вижу как это сделать. Это фактически надо в рантайм проводить декомпиляцию кода, чтобы вытащить какие свойства бинов и в каком контексте (фильтры, сортировка и т.д.) используются.

В Скала намного больше мета-информации доступно, и то к ЛИНКу даже близко не приблизились. Правда макросы сейчас пилят, вот на макросах уже можно будет ЛИНК сделать.

Если что, везде, где я пишу ЛИНК, я имею ввиду LINQ2SQL

Здравствуйте, avpavlov, Вы писали:

A>LINQ (если говорить про его применение в SQL) чуть-чуть о другом. Он умеет по Ява коду сгенерировать SQL код. Лямбды в Ява8 даже рядом такого не позволят сделать.
Он умеет ещё и запрос провалидировать на базе в compile-time. Понятно что это не только Query DSL, а целая инфраструктура.

A>Это уже LINQ получится. Но я не вижу как это сделать. Это фактически надо в рантайм проводить декомпиляцию кода, чтобы вытащить какие свойства бинов и в каком контексте (фильтры, сортировка и т.д.) используются.
Почему? Вместо строковых литералов будут лямбды со ссылками на getter-ы, например.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, avpavlov, Вы писали:

A>>LINQ (если говорить про его применение в SQL) чуть-чуть о другом. Он умеет по Ява коду сгенерировать SQL код. Лямбды в Ява8 даже рядом такого не позволят сделать.
B>Он умеет ещё и запрос провалидировать на базе в compile-time. Понятно что это не только Query DSL, а целая инфраструктура.

A>>Это уже LINQ получится. Но я не вижу как это сделать. Это фактически надо в рантайм проводить декомпиляцию кода, чтобы вытащить какие свойства бинов и в каком контексте (фильтры, сортировка и т.д.) используются.
B>Почему? Вместо строковых литералов будут лямбды со ссылками на getter-ы, например.

поля — это ещё не весь запрос

Как превратить

from(...).where(bean -> bean.id == 1)

в

from bean where bean.id == 1

? (хинт: "== 1" достать не так просто )

Здравствуйте, avpavlov, Вы писали:

A>Как превратить
A>from(...).where(bean -> bean.id == 1)
A>from bean where bean.id == 1

Так же как и сейчас в Java — заменить на .eq(1)

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, avpavlov, Вы писали:

A>>Как превратить
A>>from(...).where(bean -> bean.id == 1)
A>>from bean where bean.id == 1

B>Так же как и сейчас в Java — заменить на .eq(1)

в таком стиле и без лямбд можно писать, наглядность получается так себе, HQL/SQL+именованные параметры намного приятнее выглядят, а при редактировании в ИДЕЕ так ещё и со всеми возможными проверками и автокомплитом получается. Ещё в пользу "SQL+именованные параметры" говорит, что его можно скопипастить и погонять на сервере через SQL редактор какой-нибудь, а потом обратно.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, avpavlov, Вы писали:

A>>Как превратить
A>>from(...).where(bean -> bean.id == 1)
A>>from bean where bean.id == 1

B>Так же как и сейчас в Java — заменить на .eq(1)

И, кстати, для этого нужны спец. бины, т.е. связка "обычные бины + лямбды" не прокатывает

Здравствуйте, avpavlov, Вы писали:

A>И, кстати, для этого нужны спец. бины, т.е. связка "обычные бины + лямбды" не прокатывает
У нас уже есть JavaFX свойства. Вот тебе и специальные бины.

Здравствуйте, avpavlov, Вы писали:

A>в таком стиле и без лямбд можно писать, наглядность получается так себе, HQL/SQL+именованные параметры намного приятнее выглядят, а при редактировании в ИДЕЕ так ещё и со всеми возможными проверками и автокомплитом получается. Ещё в пользу "SQL+именованные параметры" говорит, что его можно скопипастить и погонять на сервере через SQL редактор какой-нибудь, а потом обратно.
Ну, в Criteria API тоже наглядностью не пахнет. Просто хотелось бы иметь compile time check.

B>Ну, в Criteria API тоже наглядностью не пахнет. Просто хотелось бы иметь compile time check.

КритериаАпи — это наихудшее решение с точки зрения наглядности и удобства, тут даже и обсуждать нечего.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, avpavlov, Вы писали:

A>>И, кстати, для этого нужны спец. бины, т.е. связка "обычные бины + лямбды" не прокатывает
B>У нас уже есть JavaFX свойства. Вот тебе и специальные бины.

ЯваФХ как-то мимо меня проскочила, а что там за свойства такие волшебные?

Здравствуйте, avpavlov, Вы писали:

A>ЯваФХ как-то мимо меня проскочила, а что там за свойства такие волшебные?

Property<Type> value = new SomeProperty<Type>();

Property<Type> valueProperty(){
   return value;
}

void setValue(Type value){
   value.set(value);
}

Type getValue(){
   return value.get();
}

Здравствуйте, avpavlov, Вы писали:

A>Как превратить

A>from(...).where(bean -> bean.id == 1)

A>в

A>from bean where bean.id == 1

A>? (хинт: "== 1" достать не так просто )

Оффтопик — ну кстати не так уж и сложно. Для

  Pred pred = new Pred() {
    @Override
    public boolean apply(int x) {
      return x == 1;
    }            
  };

ASM выдаёт вот такое:

L219848480
4                // push 1
160 L1735414378  // if top() != arg1 then goto L1735414378
4                
172              // return 1
L1735414378
3                
172              // return 0
L2134041139

Но дальше, конечно, придётся включать голову

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, avpavlov, Вы писали:

A>>ЯваФХ как-то мимо меня проскочила, а что там за свойства такие волшебные?
B>[java]
B>Property<Type> value = new SomeProperty<Type>();

Ну всё равно придётся на ОРМ как-то натягивать, я так понял, из коробки они даже с JPA не сопрягли

A>Но дальше, конечно, придётся включать голову

Про декомпиляцию я говорил с самого начала. Это как раз то, чего ЛИНК позволяет избежать, взяв эту работу на себя.

Здравствуйте, avpavlov, Вы писали:

A>Ну всё равно придётся на ОРМ как-то натягивать, я так понял, из коробки они даже с JPA не сопрягли
Да, через задницу эти JavaFX свойства получились. JEE вообще с древности не предполагает что клиент-сервеная комуникация может быть без тупокого DTO копипаста.
Поэтому никто и не думал даже как эти свойства на сервере использовать.

Если говорить вообще про лямбды, то пока ничего толкового про их использовании в QueryDSL я не видел.

Здравствуйте, avpavlov, Вы писали:


A>>Но дальше, конечно, придётся включать голову

A>Про декомпиляцию я говорил с самого начала. Это как раз то, чего ЛИНК позволяет избежать, взяв эту работу на себя.

Справедливости ради, добавлю, что там не только LINQ работает, но и компилятор и рантайм-библиотеки.
Одна из самых шикарных фич .NET — это захват выражения в виде AST (приоизводное от класса System.Linq.Expressions.Expresssion)
и возможность это AST в рантайме интерпретировать. Чем, собственно, тот же Entity Framework и пользуется,
транслируя LINQ-выражения в SQL-запросы. В Java8, похоже, ничего подобного сделать не получится.
Максимум, что я могу вообразить, это получение дескриптора свойства каким-то путём из java.lang.invoke.CallSite,
но этого недостаточно. Нет способа вытащить сложные выражения, как уже в треде упомянули.

A>>Про декомпиляцию я говорил с самого начала. Это как раз то, чего ЛИНК позволяет избежать, взяв эту работу на себя.

BB>Справедливости ради, добавлю, что там не только LINQ работает, но и компилятор и рантайм-библиотеки.
BB>Одна из самых шикарных фич .NET — это захват выражения в виде AST (приоизводное от класса System.Linq.Expressions.Expresssion)
BB>и возможность это AST в рантайме интерпретировать. Чем, собственно, тот же Entity Framework и пользуется,
BB>транслируя LINQ-выражения в SQL-запросы.

Ну так я и написал — "избежать декомпиляции"

avpavlov,

A>В Скала намного больше мета-информации доступно, и то к ЛИНКу даже близко не приблизились. Правда макросы сейчас пилят, вот на макросах уже можно будет ЛИНК сделать.

Твои сведения либо сильно искажены, либо устарели. Typesafe Slick полностью повторяет Linq, а в версии 2.0 идëт намного дальше в сторону NoSql баз данных.

Макросы позволяют более эффективно генерировать запросы и выдавать более человеческие ошибки (т.н. direct query Api), функционал же доступен уже сейчас через lifted api.

LCR>Твои сведения либо сильно искажены, либо устарели. Typesafe Slick полностью повторяет Linq,

Либо ты смотришь через розовые очки

Сравним

LIN2SQL — обрати внимание, компилятор подтянул имена CompanyName и Phone в кортеж, поэтому нам не надо помнить, что там первое, что второе

var q =
from c in db.Customers
where c.City == "London"
select new { c.CompanyName, c.Phone };
foreach(var c in q)
Console.WriteLine("{0}, {1}", c.CompanyName, c.Phone);

Slick — старые добрые _1 и _2

// Perform a join to retrieve coffee names and supplier names for
    // all coffees costing less than $9.00
    println("Manual join:")
    val q2 = for {
      c <- coffees if c.price < 9.0
      s <- suppliers if s.id === c.supID
    } yield (c.name, s.name)
    for(t <- q2) println("  " + t._1 + " supplied by " + t._2)

Ну и синтаксис у Линка куда ближе к реальному СКЛ, чем у Слика

avpavlov,

LCR>>Твои сведения либо сильно искажены, либо устарели. Typesafe Slick полностью повторяет Linq,
A>Либо ты смотришь через розовые очки

Возможно.

A>Сравним
A>LIN2SQL — обрати внимание, компилятор подтянул имена CompanyName и Phone в кортеж, поэтому нам не надо помнить, что там первое, что второе

Во-первых. Компилятор C# конечно молодец, однако всё что здесь делается — это используется анонимный тип с именованными полями.
Аналог в Скала тоже можно нарисовать при желании:

    case class Supply(coffeeName: String, supplierName: String)

    // Perform a join to retrieve coffee names and supplier names for
    // all coffees costing less than $9.00
    println("Manual join:")
    val q2 = for {
      c <- coffees if c.price < 9.0
      s <- suppliers if s.id === c.supID
    } yield Supply(c.name, s.name)
    for(t <- q2) println("  " + t.coffeeName + " supplied by " + t.supplierName)

Во-вторых, речь шла о захвате AST (в терминологии Expression Tree) и генерации по нему SQL инструкций. И утверждалось, что де Скала даже близко не стоит. Ответ — стоит, и даже умеет кое-что большее.

A>Ну и синтаксис у Линка куда ближе к реальному СКЛ, чем у Слика
Это необязательное требование Linq, более того спорное — Linq-выражения выглядят чуждо, интеллисенс на них работает криво и многим это не нравится. Исключительно синтаксический сахар.
В Скала такой сахар отсутствует (точнее никому не потребовалось его изобретать), но с другой стороны, в Скала не потребовались и спец. костыли для поддержки нового синтаксиса, а вся работа делается на привычном и поддерживаемом синтаксисе.

Здравствуйте, lazy-cjow-rhrr, Вы писали:

A>>Ну и синтаксис у Линка куда ближе к реальному СКЛ, чем у Слика
LCR>Это необязательное требование Linq, более того спорное — Linq-выражения выглядят чуждо, интеллисенс на них работает криво и многим это не нравится. Исключительно синтаксический сахар.
LCR>В Скала такой сахар отсутствует (точнее никому не потребовалось его изобретать), но с другой стороны, в Скала не потребовались и спец. костыли для поддержки нового синтаксиса, а вся работа делается на привычном и поддерживаемом синтаксисе.

Slick идёт нафиг не в последнюю очередь как раз из-за синтаксиса: переформулировать простейший group by на for comprehensions — да ну его нафиг. А уж если что посложнее приспичит...

Здравствуйте, lazy-cjow-rhrr, Вы писали:

LCR>Во-первых. Компилятор C# конечно молодец, однако всё что здесь делается — это используется анонимный тип с именованными полями.
LCR>Аналог в Скала тоже можно нарисовать при желании:

Не, это не аналог. Это рисование нового класса для каждого кортежа. Линк делает тоже самое, но за сценой и не заставляет программиста об этом думать.

LCR>

LCR>    case class Supply(coffeeName: String, supplierName: String)
LCR>    } yield Supply(c.name, s.address)
LCR>    for(t <- q2) println("  " + t.coffeeName + " supplied by " + t.supplierName)
LCR>

См. выделенное. Я исправил, а Скала и не заметила, а ЛИНК даст компайл-тайм еррор и заставит меня убедиться, что логика приложения не нарушена

LCR>Во-вторых, речь шла о захвате AST (в терминологии Expression Tree) и генерации по нему SQL инструкций. И утверждалось, что де Скала даже близко не стоит. Ответ — стоит, и даже умеет кое-что большее.

Нет, утверждалось что без макросов не стоит. С макросами стоит, но это ещё мало где с умом прикручено.

LCR>Это необязательное требование Linq, более того спорное — Linq-выражения выглядят чуждо, интеллисенс на них работает криво и многим это не нравится. Исключительно синтаксический сахар.

А мне нравится синтаксис SQL

avpavlov,

LCR>>Во-первых. Компилятор C# конечно молодец, однако всё что здесь делается — это используется анонимный тип с именованными полями.
LCR>>Аналог в Скала тоже можно нарисовать при желании:

A>Не, это не аналог. Это рисование нового класса для каждого кортежа. Линк делает тоже самое, но за сценой и не заставляет программиста об этом думать.

Классы моделей в любом случае нужны, и их можно (и нужно) здесь использовать. Анонимные классы в C# имеют помимо указанных тобой достоинств и ряд недостатков и ограничений, так что предпочтительнее использовать нормальные классы.

LCR>>    case class Supply(coffeeName: String, supplierName: String)
LCR>>    } yield Supply(c.name, s.address)
LCR>>    for(t <- q2) println("  " + t.coffeeName + " supplied by " + t.supplierName)

A>См. выделенное. Я исправил, а Скала и не заметила, а ЛИНК даст компайл-тайм еррор и заставит меня убедиться, что логика приложения не нарушена

Что-то, аргументация несколько однобокая и неубедительная. Попробуй сейчас не заметить:

    } yield Supply(coffeeName = c.name, supplierName = s.address)

Совершенно аналогично ты и в конструктор анонимного типа можешь передать неправильное значение (случай 1). Скажешь, не было?

new {CoffeeName = c.Name, SupplierName = s.Address} // 1
new {c.Name, s.Address} // 2

Есть определённое преимущество у C# в случае (2). По мне, так весьма частный случай, когда нам не нужно использовать модели (почему-то). Обычно всё-таки создавать модели нужно.

LCR>>Во-вторых, речь шла о захвате AST (в терминологии Expression Tree) и генерации по нему SQL инструкций. И утверждалось, что де Скала даже близко не стоит. Ответ — стоит, и даже умеет кое-что большее.

A>Нет, утверждалось что без макросов не стоит. С макросами стоит, но это ещё мало где с умом прикручено.

Синтаксический сахар необязателен. Что-то ещё?

A>А мне нравится синтаксис SQL
На здоровье. Мне — нравятся HOF.

LCR>Что-то, аргументация несколько однобокая и неубедительная. Попробуй сейчас не заметить:
LCR>

LCR>    } yield Supply(coffeeName = c.name, supplierName = s.address)
LCR>

ЧТД. Требуется вводить coding rules и следить, чтобы их все соблюдали, вместо перекладывания на компилятор.

LCR>Совершенно аналогично ты и в конструктор анонимного типа можешь передать неправильное значение (случай 1). Скажешь, не было?
LCR>new {CoffeeName = c.Name, SupplierName = s.Address} // 1

ЧТД. Если использование ЛИНКА намеренно ухудшить, то получится как в Скале

LCR>Синтаксический сахар необязателен. Что-то ещё?

Если синтаксический сахар необязателен, то вообще вся эта тема не нужна и непонятно зачем ты в неё влез. Работу с базой делали ещё на Коболе 50 лет назад и не жужжали.

A>>А мне нравится синтаксис SQL
LCR>На здоровье. Мне — нравятся HOF.

Вот и разработчикам библиотек для Скала нравится. Из-за этого так и будем иметь на выходе УГ, пока за разработку не возьмётся человек, которому нравится SQL

dimgel,

D>Slick идёт нафиг не в последнюю очередь как раз из-за синтаксиса: переформулировать простейший group by на for comprehensions — да ну его нафиг. А уж если что посложнее приспичит...

А что не так? Работаешь с таблицами как с массивами и в ус не дуешь — интеллисенс и типобезопасность в комплекте

session.withTransaction {
  // seek for the jobs that have specified status and earlier than lowerBound and select the oldest one
  val jobsOpt = Query(schema.Jobs)
    .filter(_.status === status)
    .filter(_.isDeleted === Active.value)
    .filter(_.fireTime <= lowerBound)
    // .sortBy(_.fireTime.desc) -- newer jobs are higher
    .sortBy(_.fireTime).firstOption
  if (jobsOpt.isDefined) {
    val job: Job = jobsOpt.get
    val jobId = job.id.get
    logger.debug(s"Job (id = $jobId) is selected to acquire")
    // try to aquire it
    val n = schema.Jobs.filter(_.id === jobId).update(job.copy(status = Status.next(status)))
    if (n > 0) {
      logger.debug(s"Job (id = $jobId) is acquired for processing")
      selectByWithDeps(jobId)
    } else {
      logger.debug(s"Job (id = $jobId) is failed to acquire")
      None
    }
  } else None
}

Если конечно у человека в прошлом опыт DBA, то тут да, будут сложности. Ну в этом случае ждите макросов, чё.

Здравствуйте, lazy-cjow-rhrr, Вы писали:

A>>А мне нравится синтаксис SQL
LCR>На здоровье. Мне — нравятся HOF.

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

avpavlov, Вы писали:

A>Если синтаксический сахар необязателен, то вообще вся эта тема не нужна и непонятно зачем ты в неё влез. Работу с базой делали ещё на Коболе 50 лет назад и не жужжали.

Ценность и польза Linq вообще не в синтаксическом сахаре. И Кобол тут непричём.

Здравствуйте, lazy-cjow-rhrr, Вы писали:

LCR>dimgel,

D>>Slick идёт нафиг не в последнюю очередь как раз из-за синтаксиса: переформулировать простейший group by на for comprehensions — да ну его нафиг. А уж если что посложнее приспичит...

LCR>А что не так? Работаешь с таблицами как с массивами и в ус не дуешь — интеллисенс и типобезопасность в комплекте

Не так то, что мне частенько приходилось нарываться на ситуации, когда два логически эквивалентных запроса, сформулированных через join и через вложенный подзапрос, дают ОООЧЕНЬ разную эффективность. Мне также приходилось заниматься оптимизацией постгреса на огромной базе, разбивая сложные запросы на сотню маленьких медведей с использованием временных промежуточных таблиц, потому что эта дрянь убей бог не хотела давать мне нужный план. И по итогам всего этого суммарно-многолетнего секса я предпочитаю иметь ПОЛНЫЙ контроль над видом генерируемого SQL, что естественным образом достигается только если статически типизированный язык запросов имеет близкий к SQL синтаксис, а не является очередным <матерно>paradigm mismatch bridge</матерно>.

dimgel,

LCR>>А что не так? Работаешь с таблицами как с массивами и в ус не дуешь — интеллисенс и типобезопасность в комплекте

D>Не так то, что мне частенько приходилось нарываться на ситуации, когда два логически эквивалентных запроса, сформулированных через join и через вложенный подзапрос, дают ОООЧЕНЬ разную эффективность. Мне также приходилось заниматься оптимизацией постгреса на огромной базе, разбивая сложные запросы на сотню маленьких медведей с использованием временных промежуточных таблиц, потому что эта дрянь убей бог не хотела давать мне нужный план. И по итогам всего этого суммарно-многолетнего секса я предпочитаю иметь ПОЛНЫЙ контроль над видом генерируемого SQL, что естественным образом достигается только если статически типизированный язык запросов имеет близкий к SQL синтаксис, а не является очередным <матерно>paradigm mismatch bridge</матерно>.

Цена абстракции-с. Зато типобезопасность, блэкджек и шлюхи, а для большой и чистой любви есть другие места.

Понятненько, спасибо за коммент, я такие вещи особенно люблю (в смысле вербализованный опыт коллег) Конечно, в твоём случае придётся использовать либо прямое исполнение SQL (в Slick тоже есть, но типобезопасность накрывается медным тазом), либо какой-нибудь примитивный враппер типа Anorm (или myBatis). Чтобы иметь полный контроль над сиквелем, генерируемом думателем (что Linq, что Slick), нужно частенько погружаться в кодяру и держать руку на пульсе логов. По виду Customers.First().CustomerOrders.SelectMany(item => item.Orders) невозможно догадаться, что эта строчка порождает кучу запросов вместо одного. Только либо знать, либо увидеть собственными глазами.

Я по своей воле тщательно избегал чересчур плотного погружения в SQL, дебри планов, повадки оптимизаторов и прочей хрени. Но однажды эта участь таки меня настигла — я примерно на 4.5 года вынужден был основательно потра...подружиться с мускулем и мелкософтовским сервером. Это был безусловно полезный и нужный опыт, я много подчерпнул для себя полезного. Но он (опыт) отложил отпечаток — с тех пор я стараюсь держать DAO слой как можно проще, пусть даже ценой какого-то ухудшения перфоманса в некритических местах. Потому что жизнь одна, а субдей много, и в каждой ещё по выводку тараканов. А ежели DAO простой как три копейки, то и возможностей что Linq, что Slick хватает с избытком. Лично я Slick, за вычетом ряда раздражающих неудобств, полностью доволен.

Здравствуйте, lazy-cjow-rhrr, Вы писали:

LCR>Цена абстракции-с. Зато типобезопасность,

Типобезопасность тут ортогональна, её и squeryl обеспечивает, который гораздо ближе к SQL, чем Slick. И точно такой же синтаксис можно на макросах обеспечить.

LCR>блэкджек и шлюхи,

Да вот что-то не видать. Сложный запрос запаришься формулировать. Разве что если работать с базой как с плоским хранилищем, то да, наверное стандартными scala-циклами удобнее.

LCR>А ежели DAO простой как три копейки, то и возможностей что Linq, что Slick хватает с избытком.

Во-во, ну а я привык в духе anemic — оптимизированная загрузка данных достаточно развесистыми запросами.

Аноним,

А>Наткнулся тут на статью по этому поводу.
А>Кто что думает по этому поводу?
А>А там есть упоминание вот этого.

Внезапно появилась новая библиотека для Scala, которая сильно использует макросовскую магию и реализует типобезопасные SQL-и, которые выглядят прямо как родные:

object Product {
  def create(name: String, price: Long)(implicit s: DBSession = AutoSession): Long = {
    sql"insert into products values (${name}, ${price})" // don't worry, it prevents SQL injection!
      .updateAndReturnGeneratedKey.apply() // returns auto-incremeneted id
  }

  def findById(id: Long)(implicit s: DBSession = AutoSession): Option[Product] = {
    sql"select id, name, price, created_at from products where id = ${id}"
      .map { rs => Product(rs) }.single.apply()
  }
}

Product.findById(123) // borrows connection from pool and gives it back after execution

Встречайте: http://scalikejdbc.org/

LCR>Внезапно появилась новая библиотека для Scala, которая сильно использует макросовскую магию и реализует типобезопасные SQL-и, которые выглядят прямо как родные:

Да, а вот магия

  withSQL {
    select
      .from(Programmer as p)
      .leftJoin(Company as c).on(p.companyId, c.id)
      .where.eq(p.isDeleted, false)
      .orderBy(p.createdAt)
      .limit(10)
      .offset(0)
  }.map(Programmer(p, c)).list.apply()

Ваще красота.

Здравствуйте, lazy-cjow-rhrr, Вы писали:

LCR>>Внезапно появилась новая библиотека для Scala, которая сильно использует макросовскую магию и реализует типобезопасные SQL-и, которые выглядят прямо как родные:
LCR>Да, а вот магия

Блин, опередили, окаянные.

Здравствуйте, lazy-cjow-rhrr, Вы писали:


LCR>>Внезапно появилась новая библиотека для Scala, которая сильно использует макросовскую магию и реализует типобезопасные SQL-и, которые выглядят прямо как родные:

LCR>Да, а вот магия
LCR>

LCR>  withSQL {
LCR>    select
LCR>      .from(Programmer as p)
LCR>      .leftJoin(Company as c).on(p.companyId, c.id)
LCR>      .where.eq(p.isDeleted, false)
LCR>      .orderBy(p.createdAt)
LCR>      .limit(10)
LCR>      .offset(0)
LCR>  }.map(Programmer(p, c)).list.apply()
LCR>

LCR>Ваще красота.

Ну не знаю. Мне, кажется, макросы [должны быть] способны на большее. В примеру выше почти всё можно было и без макросов сделать. Только алиасы да проперти бинов. Причём в отсутствие макросов от пропертей можно было бы отказаться и сделать из них дескрипторы колонок, тогда только алиасы бы нереализованными остались.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, lazy-cjow-rhrr, Вы писали:

LCR>>>Внезапно появилась новая библиотека для Scala, которая сильно использует макросовскую магию и реализует типобезопасные SQL-и, которые выглядят прямо как родные:
LCR>>Да, а вот магия

D>Блин, опередили, окаянные.

Если ты хотел что-то написать, то пиши. Они ещё никого не опередили

LCR> sql"select id, name, price, created_at from products where id = ${id}"

А здесь внутри СКЛных строк компайл-тайм проверка или нет?

Здравствуйте, avpavlov, Вы писали:

D>>Блин, опередили, окаянные.

A>Если ты хотел что-то написать, то пиши. Они ещё никого не опередили

Пишу и буду писать. Чужим фреймворкам в таких тонких вопросах доверять нельзя, это я уже понял. К тому же вряд ли у них есть поддержка prepared statements и компиляции императивного кода в хранимки.

Здравствуйте, avpavlov, Вы писали:

A>Ну не знаю. Мне, кажется, макросы [должны быть] способны на большее. В примеру выше почти всё можно было и без макросов сделать.

В squeryl сделано без макросов. Дико коряво и неэффективно. А на макросах и удобнее (не надо собственные операторы изобретать взамен == и !=, например) и весь парсинг в компайл-тайме, а в рантайм падает уже минималистичный jdbc-код (ну, должен, по крайней мере).

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, avpavlov, Вы писали:

A>>Ну не знаю. Мне, кажется, макросы [должны быть] способны на большее. В примеру выше почти всё можно было и без макросов сделать.

D>В squeryl сделано без макросов. Дико коряво и неэффективно. А на макросах и удобнее (не надо собственные операторы изобретать взамен == и !=, например) и весь парсинг в компайл-тайме, а в рантайм падает уже минималистичный jdbc-код (ну, должен, по крайней мере).

А они и не изобретали Тупо сделали .eq() Так что макросы они пока использовали только для галочки, а не ради новой функциональности

Здравствуйте, avpavlov, Вы писали:

A>А они и не изобретали Тупо сделали .eq() Так что макросы они пока использовали только для галочки, а не ради новой функциональности

Тогда ХЗ что им мешало заюзать ==. На уровне кода макроса разницы никакой вообще. (Впрочем, я не всматривался ещё, может там вместо полноценных выражений в where костыли какие-нибудь.)