Comments 13
Было бы гораздо проще оценить DSL, если бы к нему были даны пояснения ;) А так получается какой-то сферический DSL для описания какой-то базы данных в вакууме.
+5
А по-моему, все просто и понятно. И код красиво расцвечен. Описания таблиц — есть. Составление запроса на DSL — есть (там где :join, :where).
Нет только того, как по этому внутреннему языку генерируется SQL, — если он вообще тут генерируется, и если я правильно понимаю логику работы с этой ORM.
Нет только того, как по этому внутреннему языку генерируется SQL, — если он вообще тут генерируется, и если я правильно понимаю логику работы с этой ORM.
-1
Во-первых, да, непонятно, как это транслируется на SQL (а скорее на функции из clojure.java.jdbc).
Во-вторых, нет никакой информации о предметной области. Например, я только в середине статьи понял, что речь идёт о какой-то игре, в которой могут принимать участие человек и бот. Что за игра — ни одного намёка.
В-третьих, записи типа
В-четвёртых, нет описания ни общих принципов, ни отдельных функций (что такое select-deep? какие ещё есть типы select-ов)?
Я понимаю, что суть статьи в том, чтобы показать возможную замену ORM. Но как их сравнить, если во всей статье всего пара реальных вызовов API, да и те не описаны.
Во-вторых, нет никакой информации о предметной области. Например, я только в середине статьи понял, что речь идёт о какой-то игре, в которой могут принимать участие человек и бот. Что за игра — ни одного намёка.
В-третьих, записи типа
:join [[table-recordtypes [:= recordtypes-id records-type_id]]]
ни разу не самоописательные. Ок, я догадался, что := — это такое равенство. Но почему вектор в векторе? Я, конечно, догадываюсь, что из-за синтаксиса JOIN, но где описание? В-четвёртых, нет описания ни общих принципов, ни отдельных функций (что такое select-deep? какие ещё есть типы select-ов)?
Я понимаю, что суть статьи в том, чтобы показать возможную замену ORM. Но как их сравнить, если во всей статье всего пара реальных вызовов API, да и те не описаны.
+3
Да, в select-e sql полностью генерируется и скармливается соответствующей функции из clojure.java.jdbc. Вообще, для всех функций backend-ом является она.
К сожалению, никакой предметной области нет. Таблицы и их минимальное содержание были придуманы только для примера.
Записи типа :join это ключевые параметры функции select (мы решили не использовать where, join и пр. в виде отдельных функций). Вектор в векторе из-за того, что в join-е могут участвовать несколько таблиц, где описание «соединения» каждой представлено в виде вектора [таблица [условия_связи]]. В данном случае в векторе описание только одной таблицы.
Согласен, описания остальных функций нет. Позже добавлю кратко.
К сожалению, никакой предметной области нет. Таблицы и их минимальное содержание были придуманы только для примера.
Записи типа :join это ключевые параметры функции select (мы решили не использовать where, join и пр. в виде отдельных функций). Вектор в векторе из-за того, что в join-е могут участвовать несколько таблиц, где описание «соединения» каждой представлено в виде вектора [таблица [условия_связи]]. В данном случае в векторе описание только одной таблицы.
Согласен, описания остальных функций нет. Позже добавлю кратко.
0
Ну и да, совсем непонятно, чем этот DSL лучше чем, например, ClojureQL:
(select (table :users) (where (= :id 5)))
(join (table :one) (table :two) :id) (join (table :one) (table :two) (where (= :one.col :two.col)))
+1
Я вас услышал. Для ваших претензий, действительно, есть объективные причины. Мне это было непонятно, потому что с языком я дел не имел, и мне все показалось красивым.
Единственное, с чем я не согласен — что не описана предметная область. Тут она, в общем-то, и не важна.
Единственное, с чем я не согласен — что не описана предметная область. Тут она, в общем-то, и не важна.
0
DSL ничем не лучше, чем ClojureQL и подобные библиотеки.
Нам нужен был язык запросов, работающий именно с нашими генерируемыми данными (таблицы, поля). Также хотелось, чтобы было реализовано одно из наших требований: получение данных из связанных по внешним ключам таблиц (в orm-е джавы это было очень удобно).
Нам нужен был язык запросов, работающий именно с нашими генерируемыми данными (таблицы, поля). Также хотелось, чтобы было реализовано одно из наших требований: получение данных из связанных по внешним ключам таблиц (в orm-е джавы это было очень удобно).
0
Спасибо. Очень хотел, чтобы человек, сильно не знакомый с самим языком, почувствовал удобство как самой библиотеки, так и возможностей clojure.
0
Я, наоборот, боялся, что получается много букв для вводной статьи, поэтому описание всех функций не привел. Сегодня постараюсь добавить.
+1
А взять-то библиотечку где?
0
Можно взять здесь github.com/mobyte/clj-rich-query
З.Ы. Код требует хорошей переработки, т.к. писался в начале изучения языка.
З.Ы. Код требует хорошей переработки, т.к. писался в начале изучения языка.
0
Sign up to leave a comment.
Есть ли жизнь без ORM?