On Tuesday, 12 November 2013 at 16:14:57 UTC, John Colvin wrote:
On Tuesday, 12 November 2013 at 15:21:16 UTC, Ellery Newcomer
wrote:
On 11/12/2013 06:38 AM, John Colvin wrote:
On Tuesday, 12 November 2013 at 13:50:49 UTC, Jacob Carlborg
wrote:
auto person = Person.where(e => e.name == "John");
Translates to:
select * from person where name = 'John'
for those of us entirely unfamiliar with linq, what is this
supposed to
do? Select people with name "John" from a collection of
people, like in
sql? It seems trivial to do this using filter, or am I missing
something...?
linq provides an interface to query any collection, but what
is interesting in this case is
Person.where(e => e.name == "John")
invokes an engine that builds the necessary sql to issue an
equivalent query to your sql database and assembles the
results into a range of Person. And it can do this for any
arbitrary predicate (well, almost. It doesn't handle function
calls to arbitrary code too well).
the .NET framework can do this because it exposes an api for
querying, building, and compiling asts.
D cannot do this because it doesn't. (and I have tried to make
it work)
oh, I see. Would AST macros really be enough to make this work
in D? "Arbitrary code" is a huge feature space in D, including
much that doesn't map well to anything outside of a relatively
low-level language, let alone SQL.
I can see it quickly becoming a nightmare that would be worse
than just issuing the predicate as an sql string or some
generic equivalent.
Actually,
s/arbitrary code/simple to moderately complex expressions that
don't call functions that aren't explicitly handled by the
translation engine/
and this is a better representation of what linq can do in e.g.
entity framework.
and you could go the route of django models, e.g.
Place.objects.filter(name="Bob's Cafe")
as long as you had enough metadata set up. you could probably get
this to work in D, but
A. it looks like crap
B. it in no way resembles sql
C. it would look like even worse crap in D (no named parameters!)
D. it doesn't readily permit you to make queries with complex
expression trees (idk, maybe something like linq's
Places.Where(p => p.Elev < 200 && Addresses.Any(a => a.State ==
p.State))
why am I arguing against this? nobody wants this, nobody asked
for this.
Also, sql is to databases what assembly is to cpus. It's low
level, [moderately] untyped, and it differs on every single
platform. provide access to it, sure, but please don't use it to
build your abstractions.
