ReQL: pluses and minuses of pipeline-style queries

[Idan Arye via Digitalmars-d]

On Sunday, 26 April 2015 at 01:03:12 UTC, Rikki Cattermole wrote:
> I'm personally moving towards a DSL.
>
> unittest {
> 	auto myQuery = """
> using webdev.base.orm.query.parser.defs # allow for D class 
> name instead of table name
> ; # end of \"sentence\"
>
> from MyModel
> where key == $0
> as simple
> # as index # but only one can be defined, two in total internal
> ; # end of \"sentence\"
>
> from MyModel
> where value contains $0
> as complex
> # as index # but only one can be defined, two in total internal
> ; # end of \"sentence\"
>
> """.query;
>
> 	MyModel[] gotValues = myQuery.simple("test");
> 	gotValues = myQuery.perform("complex", "another");
> }
>
> Pros:
> - Runtime reloadability
> - Runtime composability
> - More flexible
> Cons:
> - It's a string

I get why people want to use a DSL based on the host language's 
constructs. The host language is built to deal with it's own 
constructs, so composing your queries from them allows you to 
easily do stuff like store query parts in variables, create 
functions that modify queries, use reflection on the queries, 
send variables and expressions from the host process directly to 
the query etc.

What do you gain from a string-based DSL? It doesn't allow you to 
do any of these things - at least not any more 
conveniently/efficiently/safely than you could with SQL strings - 
so essentially it's just a language to replace SQL.

Now, Some languages are so messed up that it's worthwhile to 
create a language the compiles to them(*cough* Javascript 
*cough*). SQL is not one of them. Even if we assume this language 
is better than SQL - is the difference enough to justify leanring 
this new language, to translate SQL errors caused by misuse of 
that langauge(or propagate and let the user deal with it), and 
deal with errors caused by bad implementation of the translation?