Странно, что Apple позволяет делать такое в приложении. Ладно, с полями ввода разобрались — они не пишутся. Но, например, end-to-end шифрование в мессенджерах ничего не значит само по себе, если можно просто писать видео с экрана пользователей. Это не должно быть нормой.
А это идея! Можно сделать методы расширения для конкретных реализаций типа JDBC для преобразования в prepared statement вместо строк. Благодарю за наводку.
Спасибо за развернутый комментарий. Приятно, когда вникают в суть статьи. Теперь по пунктам:
1) хм???
2) Абсолютно верно. Это вообще решается плэйсхолдерами и передачей аргументов в prepared statements, т.е. хэндлиться должно уровнем ниже. Думаю стоит этот момент задокуметировать, чтобы не сбивать с толку людей.
3) Никакой магии не происходит "за кадром". Вызывать DDL нужно руками. Библиотека не является средством миграции или ORM. Сейчас цель сделать этакий билдер для SQL запросов.
4) Правда. Как доберусь до подзапросов, будет немного лучше.
5) Очень может быть. Библиотека в продакшене используется только на Android (SQLite). Может, я что-то упустил из других диалектов.
6) Очень может быть
7) Не совсем понял. С LINQ я "на ты", т.к. по основному роду деятельности я дотнетчик.
8) Согласен. Полностью проверить запросы на этапе компиляции не получится, но можно добиться некоторого улучшения по сравнению с SQL. В рантайме автоинкремент не проверяется.
Что касается ипользования — эта библиотека вытекла из реального проекта, т.е. около года она вполне себе используется. Но возможно проблема в том, что реально применяется пока только на Android, и я не могу видеть всех юзкейсов и проблем от других пользователей.
Я бы поспорил с этим. Прежде чем производить какое-то действие, нужно знать, над чем действие будет произведено. Выборка из нескольких таблиц это всего-лишь синтаксический сахар над конструкцией JOIN.
С этим фактом, кстати, связаны множество проблем автокомплита SQL в IDE: невозможно дать подсказку по колонкам таблицы без информации о том, из какой таблицы будет выборка.
Нет, это не ограничение языка, так написана библиотека. Select, являясь завершающим вызовом в любом случае будет дублироваться. Над Where можно подумать еще.
x = from(Employees)
.join(Organizations).on { e, o -> o.id eq e.organizationId }
if (some external condition)
y = x.join(Countries).on { e, o, c -> e.country_id = c.id } # Уже 3 переменные в роли алиасов
.where { e, o, c -> e.organizationId eq 1 }
.select { e, o, c -> e.id .. e.name .. o.name }
else
y = x.where { e, o -> e.organizationId eq 1 }
.select { e, o -> e.id .. e.name .. o.name }
Можно. Но нужно ли? Как по мне, так eq лаконичнее, плюс там все операторы придется так делать. Еще я не уверен, что DEX позволит такое имя, не хотелось бы исключать Android.
Альтернатива range это что-нибудь типа listOf, очень многословно получится. Что касается eq, то переопределить == не получится, т.к. он обязан вернуть Boolean, а для нужд библиотеки подойдет только внутренний тип Expression.
Вот что-то не получается ни у кого сделать такое. Обычно, либо оно централизованное, либо очень неудобное и убогое. На Tox можно для примера посмотреть.
Хм. Даже не знаю. Многие жаловались на Windows, но там проблему вроде решили: https://github.com/x2bool/egram.tel/issues/1. А я сам на маке, и оно у меня точно работает. Если не трудно, заведете issue и стэктрейс запостите туда?
Плюс еще и посреди чистого поля, вдали от цивилизации.
Странно, что Apple позволяет делать такое в приложении. Ладно, с полями ввода разобрались — они не пишутся. Но, например, end-to-end шифрование в мессенджерах ничего не значит само по себе, если можно просто писать видео с экрана пользователей. Это не должно быть нормой.
Да, JOOQ в чем то похож своим подходом. На Expression Tree даже тикет вроде где-то был, но пока не приоритетная фича для разработчиков Kotlin :(
В Kotlin не получится сделать аналог IQueryable — нужна поддержка Expression в языке. На счет decomposition посмотрите эту ветку: https://habr.com/post/414483/#comment_18792121
Функции на подходе. Условные выражения тоже вполне реализуемы.
Это частный случай подзапроса. Подзапросы еще не готовы, но первые в очереди на реализацию. Будет.
А это идея! Можно сделать методы расширения для конкретных реализаций типа JDBC для преобразования в prepared statement вместо строк. Благодарю за наводку.
Спасибо за развернутый комментарий. Приятно, когда вникают в суть статьи. Теперь по пунктам:
1) хм???
2) Абсолютно верно. Это вообще решается плэйсхолдерами и передачей аргументов в prepared statements, т.е. хэндлиться должно уровнем ниже. Думаю стоит этот момент задокуметировать, чтобы не сбивать с толку людей.
3) Никакой магии не происходит "за кадром". Вызывать DDL нужно руками. Библиотека не является средством миграции или ORM. Сейчас цель сделать этакий билдер для SQL запросов.
4) Правда. Как доберусь до подзапросов, будет немного лучше.
5) Очень может быть. Библиотека в продакшене используется только на Android (SQLite). Может, я что-то упустил из других диалектов.
6) Очень может быть
7) Не совсем понял. С LINQ я "на ты", т.к. по основному роду деятельности я дотнетчик.
8) Согласен. Полностью проверить запросы на этапе компиляции не получится, но можно добиться некоторого улучшения по сравнению с SQL. В рантайме автоинкремент не проверяется.
Что касается ипользования — эта библиотека вытекла из реального проекта, т.е. около года она вполне себе используется. Но возможно проблема в том, что реально применяется пока только на Android, и я не могу видеть всех юзкейсов и проблем от других пользователей.
Я бы поспорил с этим. Прежде чем производить какое-то действие, нужно знать, над чем действие будет произведено. Выборка из нескольких таблиц это всего-лишь синтаксический сахар над конструкцией JOIN.
С этим фактом, кстати, связаны множество проблем автокомплита SQL в IDE: невозможно дать подсказку по колонкам таблицы без информации о том, из какой таблицы будет выборка.
Нет, это не ограничение языка, так написана библиотека. Select, являясь завершающим вызовом в любом случае будет дублироваться. Над Where можно подумать еще.
Либа ничего не "накомпайлит". Запросы транслируются один в один.
Так — нет. Можно, что-то такое:
Можно. Но нужно ли? Как по мне, так eq лаконичнее, плюс там все операторы придется так делать. Еще я не уверен, что DEX позволит такое имя, не хотелось бы исключать Android.
Можно в методе прямо прописать, можно строкой прямо. Не уверен, что это чем-то лучше. Есть другие идеи?
Условные джоины вполне возможны:
1) Делаете базовый запрос
2) Дополняете джоинами по условию, в зависимости от ваших потребностей
Exposed больше ORM и только для JDBC. А я, в основном, на Android использую.
Альтернатива range это что-нибудь типа listOf, очень многословно получится. Что касается eq, то переопределить == не получится, т.к. он обязан вернуть Boolean, а для нужд библиотеки подойдет только внутренний тип Expression.
Сразу представляется плагин для Алисы от сторонних разработчиков (ФСБ)
Вот что-то не получается ни у кого сделать такое. Обычно, либо оно централизованное, либо очень неудобное и убогое. На Tox можно для примера посмотреть.
Хм. Даже не знаю. Многие жаловались на Windows, но там проблему вроде решили: https://github.com/x2bool/egram.tel/issues/1. А я сам на маке, и оно у меня точно работает. Если не трудно, заведете issue и стэктрейс запостите туда?