LINUX.ORG.RU

Состряпал конструктор SQL на Java

 , , , ,


1

1

Несколько лет назад при разработке одного крупного проекта на PHP, который только и делал что писал, читал и обновлял тонны данных в SQL, я решил написать для этого проекта конструктор SQL-запросов, который тогда сильно облегчил мне жизнь и по сей день помогает мне и мои коллегам в ежедневной работе. Дело в том, что выложить этот конструктор в общественный доступ я не могу, так как проект принадлежит не мне, да и сильно завязан этот конструктор на наш фреймворк.

В связи с чем я решил разработать его аналог на Java: https://github.com/r0ck3r/IQL

Документация доступна там же, а вот некоторые примеры использования:

Connection con = DriverManager.getConnection("jdbc:mysql://server/database", properties);

Вставка данных:

IQL iql = new IQL(con);  
iql.addTable("mytable");  
iql.setInsertRows("name %s", "register_date %d", "level %i");  
iql.insert("User1", "17.05.2017", 4);  
iql.insert("User2", "12.03.2016", 5);  
Statement st = iql.getStatement();

Сгенерирует следующее:

INSERT INTO `mytable`(`name`, `register_date`, `level`) VALUES ('User1', 1494968400, 4), ('User2', 1457730000, 5)

Обновление данных:

IQL iql = new IQL(con);  
iql.addTable("organisations");  
iql.setUpdateRows("name %s", "address %s");  
iql.update("New orgname", "New address");  
iql.whereId(112);  
PreparedStatement ps = iql.getStatement();
Сгенерирует следующее:
UPDATE `organisations` SET `name` = 'New orgname', `address` = 'New address' WHERE `organisations`.`id` = 112
при этом, если для операций обновления или удаления не указан where, то будет сгенерировано исключение

Пример выборки:

IQL iql = new IQL(con);
iql.addTable("domains").select("subdomain subdomain", "domain domain").where("domain %s", IQL.ISNTNULL);
iql.addTable("orgs").select("org_name name", "org_address address").where("org_name %s", IQL.LIKE, "%организация%");
iql.join(2, "id", 1, "org_id"); //присоединить к таблице №2 (orgs) таблицу №1 domains по полям id из orgs к org_id из domains
String SQL = iql.getSQL();

Создаст следующий SQL-код:

SELECT 
`domains`.`subdomain` AS `subdomain`, 
`domains`.`domain` AS `domain`, 
`orgs`.`org_name` AS `name`, 
`orgs`.`org_address` AS `address` 
FROM `orgs` 
JOIN `domains` ON `orgs`.`id` = `domains`.`org_id` 
WHERE 
`domains`.`domain` IS NOT NULL AND 
`orgs`.`org_name` LIKE '%организация%'

В общем, кому надо - используйте

★★★★★
Ответ на: комментарий от Deleted

Больше ада будет когда встанет вопрос тестирования запросов,

Тестировать строчки? Ладно, генератор sql - да, но запрос? Всегда делались интеграционные тесты против бизнес+база, потому как бывает бизнеслогика размазана между кодом и sql.

Aber ★★★★★
()
Ответ на: комментарий от Aber

Тестировать строчки?

Blah.java тоже строчки 8)

бывает бизнеслогика размазана между кодом и sql.

поздравляю, у вас антипаттерн

Deleted
()
Ответ на: комментарий от Deleted

поздравляю, у вас антипаттерн

Добро пожаловать в реальный мир. В идеальном мире конечно sql без подзапросов. А может весь бизнес в sql? Но sql это write only dsl. Давайте признаемся в этом, sql - нечитаемый DSL. Конечно можно написать на чем угодно нечитаемый код, но как не старайся сложный sql нельзя написать читаемым, а тем более в реальном мире его пишут с хаками смотря на получаемый query plan и заботясь только о производительности.

Blah.java тоже строчки 8)

Я не понял про «не тестируют». Если не разделяют код от sql? Да наверное все тестируют ингеграционно с транзакциями, от этого куда больше пользы.

Aber ★★★★★
()
Ответ на: комментарий от Aber

Добро пожаловать в реальный мир.

И вам не хворать.

В идеальном мире конечно sql без подзапросов.

Состряпал конструктор SQL на Java (комментарий)

Там написано «с вложенными селектами», и ты отвечал на этот комментарии, ты вообще его читал? 8)

Deleted
()
Ответ на: комментарий от Deleted

ну да между языком разметки (html) и языком программирования jsx (это js с некоторым dsl) - разницы никакой, ну вааще

Да никакой, никакой, не переживай ты так :)

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

Почему перестанет работать-то?

Больше ада будет когда встанет вопрос тестирования запросов, но кодеров это не волнует, я правильно понимаю?

И тут я тебя не понимаю. Какие у тебя проблемы с тестированием запросов?

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Почему перестанет работать-то?

Да ты никогда нормального то «жирного» запроса и не видел похоже . Могу пожелать тебе найти почему «селект в 2-3 экрана» размером и с десятком подставляемых параметров не возвращает результат 8)

Какие у тебя проблемы с тестированием запросов?

ты давай стрелки не переводи 8) вот ты отдельно запросы тестируешь?

Deleted
()
Ответ на: комментарий от Deleted

Там написано «с вложенными селектами»

Поправка: я считаю что в идеальном мире запрос будет без сабселектов. Ты лучше скажи как так, подзапрос в запросе есть а бизнес логика не размазана? А еще лучше про «sql перерастет размер в пол экрана». Для того есть только один ответ - сложные бизнес правила, эти правила описывают связи между сущностями которые нужно достать и показать, вот и полается, чтоб либо в коде нет никаких правил, либо как я и сказал все размазалось.

Aber ★★★★★
()
Ответ на: комментарий от Aber

Я без звезд, редактировать не могу. s/для того/для этого/g, s/полается/получается/g

Aber ★★★★★
()
Ответ на: комментарий от Deleted

Нет уж доктор! Когда я делаю crud у меня болит :) Хотя да, с чистой выборкой то проблем вроде нет, а вот выборка с последующем изменением приводят к тому, что бизнес и там и там.

Aber ★★★★★
()
Ответ на: комментарий от Aber

выборка с последующем изменением приводят к тому, что бизнес и там и там.

ты про select for update ? и где там у тебя логика?

Deleted
()
Ответ на: комментарий от Aber

А может весь бизнес в sql? Но sql это write only dsl. Давайте признаемся в этом, sql - нечитаемый DSL. Конечно можно написать на чем угодно нечитаемый код, но как не старайся сложный sql нельзя написать читаемым, а тем более в реальном мире его пишут с хаками смотря на получаемый query plan и заботясь только о производительности.

Чойта нечитаемый, у меня почему-то читаемый

Harald ★★★★★
()
Ответ на: комментарий от Harald

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Да ты никогда нормального то «жирного» запроса и не видел похоже .

Для отчётов писал пару раз. Так да, стараюсь такую гадость не рожать, вдруг потом придётся сопровождать.

Могу пожелать тебе найти почему «селект в 2-3 экрана» размером и с десятком подставляемых параметров не возвращает результат 8)

Спасибо за пожелание, понадобится — обязательно найду. Но ты всё равно говоришь загадками. Вот есть запрос в отдельном файле. Окей. Есть запрос в .java-файле. Каким макаром первый вариант позволяет что-то там искать быстрей, чем второй? Ну нужен мне запрос в файле — мышкой выделил и вставил, 2 секунды. Вставил назад, ещё 2 секунды. Научить тайной магии прямоугольного выделения альтом в идее?

ты давай стрелки не переводи 8) вот ты отдельно запросы тестируешь?

Да я вообще мало что тестирую, мне платят за код, который работает, а не тестирует, так уж получается. Если возникает нужда — тестирую, правда не отдельно запрос, а весь метод, работающий с базой.

Legioner ★★★★★
()
Ответ на: комментарий от Deleted

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Legioner

Ну нужен мне запрос в файле — мышкой выделил и вставил, 2 секунды. Вставил назад, ещё 2 секунды. Научить тайной магии прямоугольного выделения альтом в идее?

Лалка, научи отлаживать запрос только перекидыванием его из идеи, я просто поржу 8) Ну или идея тебе пособирает список параметров и расскажет что куда совать и вот это все и засунет в редактор? Шо нет?

Да я вообще мало что тестирую

да ты вообще работаешь в одиночку похоже, и в write only стиле 8)

Deleted
()
Ответ на: комментарий от Deleted

Да нет, я про то, что нужно вывести данные пользователю в красивой формочке из нескольких таблиц, где пользователь может некоторые значения поменять. Получится что бизнеслогика для выборки будет в sql а для того как и что можно менять уже в коде. По факту при непонятках девелоперу приходится и sql пахать и код.

Aber ★★★★★
()
Ответ на: комментарий от Deleted

sql-говнокод

Единственные способ представить сложную выборку с несколькими сабселектами в приемлемом виде только with statement. Язык других абстракций не предлагает. Сложный sql нечитаем, это печально, но это так. Нельзя просто взять и дописать запрос, надо достаточно много времени потратить на его изучение, да так, что ощущения с «sql-говнкод» сменятся на «как будто я написал».

Aber ★★★★★
()
Ответ на: комментарий от Aber

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

таким макаром «концептуальная целостность» не нарушалась, в другом проекте где использовался JPA применялся похожий подход, хотя и примитивнее, ну потому что JPA - убожество

Deleted
()
Ответ на: комментарий от Deleted

Звучит прямо как описание работы orm с базой ;) Звучит сложно... но возможно. Есть где подсмотреть примеры? Может открытый проект со схожим подходом?

Aber ★★★★★
()

Безотносительно полезности приложения.

IQL.java 1099 строк

У меня аж рантаймэксепшн выскочил. Переписывай это говно!

anonymous
()
Ответ на: комментарий от Legioner

Хотя в 2017-м наверное уже надо под Kotlin такое делать

А в 2018 под что будем делать, когда хайп стихнет? Какой там следующий ЯП под JVM хайпить будем? Груви похайпили, Скалу похайпили, Кложуру слега цепанули, что там следующее? Может C# на JVM портанут (как никак 10-ка намечается)? Можно будет неплохой хайп устроить...

foror ★★★★★
()
Ответ на: комментарий от anonymous

Теперь можешь удалить свое поделие.

Лучше удали поделие по твоей ссылке и в мире станет чуточку лучше

foror ★★★★★
()
Ответ на: комментарий от Legioner

Вот что реально нужно, это удобная работа с результатом запроса и удобная параметризация запроса.

Что-то типа fluent-jdbc?

foror ★★★★★
()

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

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 2)
Ответ на: комментарий от foror

Хотя в 2017-м наверное уже надо под Kotlin такое делать

А в 2018 под что будем делать, когда хайп стихнет? Какой там следующий ЯП под JVM хайпить будем? Груви похайпили, Скалу похайпили, Кложуру слега цепанули, что там следующее? Может C# на JVM портанут (как никак 10-ка намечается)? Можно будет неплохой хайп устроить...

У тебя плохое чутьё. Kotlin это не хайп, Kotlin это будущее Java. Груви, кложуры — да, хайп. Scala это крутая штука, но не для всех. А Kotlin для всех. В том и фишка Kotlin-а, в нём нет ничего хайпового. Это просто добротно сделанный наследник Java. Единственное, что раньше слегка напрягало — всё-таки Jetbrains это мелкая компания по мировым меркам. Сейчас над ним появился штамп Google и это напряжение спало.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Kotlin это будущее Java

Джава может запросто ввести этот сахарок (val и var в процессе), особенно после https://jug.ru/2017/05/shorten-release-cycle/ и в чем будет тогда нужность котлина? После он просто будет не нужен, тот же AOT опять же в процессе и для джавы.

появился штамп Google и это напряжение спало

И что? Гугл будет на нём Gmail переписывать или другие свои APK?

А Kotlin для всех.

За счет андроида хайпанул, за счет плохой поддержки современной джавы. Да, слега покупается в лучах славы, но после вот этого http://www.opennet.ru/opennews/art.shtml?num=46542 у него просто нет шансов.

В целом, вчера читал на хабре коменты и удовлетворен как коллеги настроены к этим поднадоевшим хайпам новых ЯП для JVM. Так что не всё потеряно.

foror ★★★★★
()
Ответ на: комментарий от Legioner

С другой стороны нужность котлина и прочих новых ЯП, чтобы подстегивать авторов джава, а иначе сидели может быть в болоте 1.4 синтаксиса в 2017 году... А так вон даже о введении pattern matching для джавы всерьез обсуждают на официальном уровне.

Так что с другой стороны он конечно нужен.

foror ★★★★★
()
Ответ на: комментарий от Deleted

ага после переноски разработки в индию, лол

Тесты же должен кто-то писать - для проектов такого уровня думаю целые тест отделы разработчиков создаются.

foror ★★★★★
()
Ответ на: комментарий от Deleted

Российская команда отвечала полностью за Java ME и за часть Java SE, в том числе за новые и старые графические библиотеки (AWT, SWING, J2D, JavaFX)

И в чем я не прав? Сливали сюда работу над легаси, ненужно и наверное какой-нибудь сапорт для местных контор.

foror ★★★★★
()
Ответ на: комментарий от foror

Тесты же должен кто-то писать
Российская команда отвечала ... и за часть Java SE, в том числе за новые и старые графические библиотеки (AWT, SWING, J2D, JavaFX)
И в чем я не прав? Сливали сюда работу над легаси,

ты если облажался, то не изворачивайся, выглядит мерзко 8)

Deleted
()
Ответ на: комментарий от foror

По информации Oracle, центр разработки в Петербурге вносит вклад в развитие интернета вещей. Такое направление, как Java ME Embedded, используемое для программирования встроенных систем (сим-карты, мобильные телефоны, GPS-приемники, «умные дома»), полностью реализуется в северной столице.

Еще одно ненужно.

foror ★★★★★
()
Ответ на: комментарий от Deleted

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

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от foror

Джава может запросто ввести этот сахарок (val и var в процессе), особенно после https://jug.ru/2017/05/shorten-release-cycle/ и в чем будет тогда нужность котлина? После он просто будет не нужен, тот же AOT опять же в процессе и для джавы.

Джава даже лямбды нормально не смогла интегрировать в язык. Checked Exceptions не пробрасываются, т.е. простейший код вида stream.forEach(writer::write); не скомпилируется. У джавы столько багажа, что новые фичи они просто не способны вводить, нужна JavaNG, которой пока на горизонте не видно.

И что? Гугл будет на нём Gmail переписывать или другие свои APK?

Есть слухи, что гугл внутри уже давно использует Kotlin. Переписывать ни одна компания ничего просто так не будет, дураков деньги бросать на ветер нет, а новый код могут и начать писать, по крайней мере в каких-то командах.

За счет андроида хайпанул, за счет плохой поддержки современной джавы.

Андроид это примерно половина пользователей Kotlin. Поэтому нет, не за счёт андроида, по крайней мере не только за счёт андроида.

Да, слега покупается в лучах славы, но после вот этого http://www.opennet.ru/opennews/art.shtml?num=46542 у него просто нет шансов.

Расшифруешь? Я не понял, какое отношение это имеет к Kotlin.

В целом, вчера читал на хабре коменты и удовлетворен как коллеги настроены к этим поднадоевшим хайпам новых ЯП для JVM. Так что не всё потеряно.

Ну раз хабра, тогда да, можно успокоиться. Я на HN читал коменты и тоже удовлетворён :)

Legioner ★★★★★
()
Ответ на: комментарий от Deleted

Тогда иди к врачу, ведешь ты себя не адекватно.

Понятно, по существу сказать нечего.

foror ★★★★★
()
Ответ на: комментарий от Legioner

Расшифруешь? Я не понял, какое отношение это имеет к Kotlin.

Это положит конец чехарде с фрагментацией андроида, а значит и с различными хаками по переносу современного джава кода на устаревшие девайсы. Так что разработчикам будет меньше боли, а значит и меньше желания менять джаву на что-то другое.

Ну раз хабра, тогда да, можно успокоиться. Я на HN читал коменты и тоже удовлетворён :)

Ну пусть будет так )

foror ★★★★★
()
Ответ на: комментарий от foror

Это положит конец чехарде с фрагментацией андроида, а значит и с различными хаками по переносу современного джава кода на устаревшие девайсы.

Может положит, а может не положит. Даже если положит, то только лет через 7 можно будет забить на текущие версии.

Так что разработчикам будет меньше боли, а значит и меньше желания менять джаву на что-то другое.

Ну если кто-то 7 лет высидит на жаве, тех понятно, только в гробу выносить останется.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Ситуации могут быть разными... Например, самсунг топит за гибкии дисплеи, скажем все начнут выпускать в 2019 смартфоны разворачивающиеся в планшеты и обратно легким движением руки. А по весу и жизни аккумуляторы в х2 раза лучше LCD. И каждый это захочет. И здесь типичный график жизненного цикла андроид версий не сработает. За короткий период куча народа обновится, особенно со старых девайсов.

Или опять же повальная мода на андроид в западных авто, так же будут иметь последние прошивки. Под которые будут обособленные (от мобайл рынка) разработчики.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.