4 ms·

I think writing DSLs for SQL makes little sense. SQL is already a declarative query DSL, why not just use it? Putting another declarative layer on top buys you

by jwr 15y ago

I think writing DSLs for SQL makes little sense. SQL is already a declarative query DSL, why not just use it? Putting another declarative layer on top buys you little (syntactic sugar for most libraries, this one additionally seems to deal with one-to-many relations, and I hope that support is read-write, not just read-only) — and isolates you from the database below. In every serious application I've worked on there was a need to use something which the DSL did not support. So why do it at all?

groovy2shoes 15y ago
In this case, an embedded DSL brings all the goodies of Lisp's code-as-data to SQL.
technomancy 15y ago
Raw SQL is not very composable, while Korma emphasizes composability on the second paragraph of the page.
- hosh 15y ago
  And composability lets you create business DSLs and macros on top of that. I've used this to good effect with Rails' Arel, but since it is still Ruby, you can't go as far unless you're willing to parse the Ruby into something more legible, like S-expressions.
its2010already 15y ago
It does make sense to be able to define business/application logic as reusable query components. For example, if your PERSON entity has TITLE, FIRST_NAME and LAST_NAME fields, that little bit of logic that concatenates them together in the right way to form a full name is something that is useful to define. Likewise, setting up a join of tables that is used many times in your application is something that Korma will let you do. Even though these components may be implementable on the database side (as user defined functions or views), it may not always be possible (or desirable) to do that way.
pradocchia 15y ago
I spend much of my time in the database, legacy and greenfield, and I would love a better DSL than SQL, something that ran directly in the database itself and targeted the planner/optimizer rather than just emitting more SQL. I would like to be able to pass a WHERE clause to a function, or a SELECT statement to a procedure, not just simple ints, or strings to be exec'd.

by jwr 15y ago

groovy2shoes 15y ago

In this case, an embedded DSL brings all the goodies of Lisp's code-as-data to SQL.

technomancy 15y ago

Raw SQL is not very composable, while Korma emphasizes composability on the second paragraph of the page.

hosh 15y ago
And composability lets you create business DSLs and macros on top of that. I've used this to good effect with Rails' Arel, but since it is still Ruby, you can't go as far unless you're willing to parse the Ruby into something more legible, like S-expressions.

its2010already 15y ago

It does make sense to be able to define business/application logic as reusable query components. For example, if your PERSON entity has TITLE, FIRST_NAME and LAST_NAME fields, that little bit of logic that concatenates them together in the right way to form a full name is something that is useful to define. Likewise, setting up a join of tables that is used many times in your application is something that Korma will let you do. Even though these components may be implementable on the database side (as user defined functions or views), it may not always be possible (or desirable) to do that way.

pradocchia 15y ago

I spend much of my time in the database, legacy and greenfield, and I would love a better DSL than SQL, something that ran directly in the database itself and targeted the planner/optimizer rather than just emitting more SQL. I would like to be able to pass a WHERE clause to a function, or a SELECT statement to a procedure, not just simple ints, or strings to be exec'd.