so and so... because the behavior depend on where that beast is sitted.
people.Take(10).Where(p=> p.Name.StartsWith("D")).Skip(1)
now try to translate it in SQL having the same behavior you have in RAM.
then, moving the Skip, the Take and the Where do it again.
and keep in mind that it is a very simple case.LINQ was wrote to be generic and it work very well in RAM but when you have to go to DB... HQL is an OO query-system and it was designed to be used for persistence in RDBMS and XML. To efficiently cover all possibles combinations of a LINQ you can wait some years. We can simplify/reduce a LINQ but the simplification/reduction is, and will be, always opinable. On Tue, Apr 12, 2011 at 2:12 PM, Darren Kopp <[email protected]> wrote: > See, I think you should always go the linq to objects route. Linq is an > abstraction that sits on top of something (objects, sql, whatever), so it's > the abstractions job to translate the intent. You should be writing (a.b != > null) && (a.b.c == x) because you don't know what you are applying it > against. What should happen is the abstraction should reduce the intent down > to what it's target is expecting. Even though you have those expressions > there doesn't mean that you need to send "a.b IS NOT NULL AND a.b.c = z.x" > if you can just write a.b.c = z.x. > > At the same time, if you can't predict the intent absolutely, then you are > going to have to fall back to sending the full intent. I think if we were > just writing out sql from the linq expression, this would be simpler. Since > this is making an hql statement, maybe it's even simpler, maybe much harder. > The question is: who should be reducing the expression? The linq provider or > the provider that takes hql and emits sql or both? Either way, somewhere the > expression should be reduced because SQL doesn't need the null check when > the null check was already done by a join (not necessarily the null check > between two values) > -- Fabio Maulo
