On 27/04/2015 1:12 a.m., Idan Arye wrote:
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?
Worse case scenario, you are free to use the raw sql function for a
query. But it will only work if its for an SQL database engine.
Also this won't compile to D.
