On 26/04/2015 1:59 a.m., w0rp wrote:
On Saturday, 25 April 2015 at 05:16:21 UTC, Andrei Alexandrescu wrote:
Found this on reddit a few days ago:
http://rob.conery.io/2015/04/17/rethinkdb-2-0-is-amazing/
A good discussion of the pros and cons of pipeline-style queries (the
ReQL query language reminiscent of D's algorithms/ranges) vs. classic
SQL.
Andrei
One thing *kind of* related that I have really enjoyed is Django's
querysets for building SQL queries. In Django, a QuerySet has methods
query yields new QuerySet objects, so you can build a set of parameters
and SQL is eventually generated and then executed to yield the results.
andrei_queryset = (
People.objects
.filter(first_name="Andrei", last_name__startswith="Al")
.order_by("-affinity_for_template_metaprogramming")
.select_related("organisation")
[0:5]
)
The above would, when evaluated, generate something like the following
in order to build the objects with.
SELECT p.*, o.* FROM people AS p
INNER JOIN organisation AS o
ON o.id = p.organisation_id
WHERE first_name = "Andrei"
AND last_name LIKE "Al%"
ORDER BY affinity_for_template_metaprogramming DESC
LIMIT 5;
I've been trying to think of a way to create something similar in D,
maybe for something like HiberateD.
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
