Здравствуйте, Аноним, Вы писали:
А>Наткнулся тут на статью по этому поводу. А>Кто что думает по этому поводу? А>А там есть упоминание вот этого.
Ну, я думаю, что лямбды это один уверенный шаг к тому чтобы отказаться от запросов и свойств в виде строковых литералов. 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 получится. Но я не вижу как это сделать. Это фактически надо в рантайм проводить декомпиляцию кода, чтобы вытащить какие свойства бинов и в каком контексте (фильтры, сортировка и т.д.) используются.
В Скала намного больше мета-информации доступно, и то к ЛИНКу даже близко не приблизились. Правда макросы сейчас пилят, вот на макросах уже можно будет ЛИНК сделать.
Здравствуйте, 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-ы, например.
Здравствуйте, 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.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, avpavlov, Вы писали:
A>>И, кстати, для этого нужны спец. бины, т.е. связка "обычные бины + лямбды" не прокатывает B>У нас уже есть JavaFX свойства. Вот тебе и специальные бины.
ЯваФХ как-то мимо меня проскочила, а что там за свойства такие волшебные?
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, avpavlov, Вы писали:
A>>ЯваФХ как-то мимо меня проскочила, а что там за свойства такие волшебные? B>[java] B>Property<Type> value = new SomeProperty<Type>();
Ну всё равно придётся на ОРМ как-то натягивать, я так понял, из коробки они даже с JPA не сопрягли
Здравствуйте, avpavlov, Вы писали:
A>Ну всё равно придётся на ОРМ как-то натягивать, я так понял, из коробки они даже с JPA не сопрягли
Да, через задницу эти JavaFX свойства получились. JEE вообще с древности не предполагает что клиент-сервеная комуникация может быть без тупокого DTO копипаста.
Поэтому никто и не думал даже как эти свойства на сервере использовать.
Если говорить вообще про лямбды, то пока ничего толкового про их использовании в QueryDSL я не видел.
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-запросы.