Hi Harald, so you basically say that LINQ is just for convenience, for the many easy queries. You just write and forget them, and they will just work. As soon as stuff gets complicated (so you need to hack around with ad hoc SQL queries) and/or performance critical (so you need to read the SQL and modify the query to generate another SQL) you'd just re-write the query in SQL or HQL and not bother with LINQ at all.
Did I get this right? It's a valid direction to take. Personally, I like to be able to use one language that takes me all the way. Once I set up my whole application infrastructure based on LINQ (implicit versioning, specifications, automatic eager fetching and paging in UI controls, tenant constraints, UI query builders, whatever), I want to be able to use this for every query, not reinvent everything for those queries that are not created using LINQ. To me, that seems much more important than being able to execute the same query against DB and memory. So I want to be able to write as many queries in LINQ as possible, and the best way to get there is to think about these queries in DB terms, not in terms of in-memory objects. To top your invalid comparison with another invalid one: What you're suggesting is like using automatic object brokers in your distributed app, and for every spot where the by-method remoting gets too slow, you just open up a HTTP connection and do it manually. ;-) So here's my opinion. I'm not a NH user, so other people will have to decide which way NH goes (maybe both). > (b) Do you really need that SQL = *semantics*? I.e., do you *want* to > *not* get the objects where both A and B are null? In all my career, I > have not seen application code that *relied* on such a result Like I said: when you join tables, you wouldn't have it any other way. And you can use multiple FROMs and a WHERE statement for joining too. > (f) What is wrong with NHibernate optimizing away the IS NULL parts > *if* the property type (e.g. int) or the mapping file tells it that the > property is not nullable (the second would be akin to the "register" > keyword mentioned above)? Nothing's wrong with that. I argued against changing the SQL depending on the value of a paramter, not depending on the type of the column. > And I would definitely not have a problem if the "purist factory" would > *not* be the default. (And yes, also that "purist factory" would not be > *that* purist - see that trailing blank example I gave in another > posting. Performance on the database is important. There's no way > around this ...). Maybe I'll try to find out how I could add this to > NHibernate - either by convincing you (the NHib team) to do this; or by > pulling it off outside NHib - as I already did with our current > "OurExpressions to HQL" generator. Having both options would definitely be interesting. The effort would have to be considered (right now there are more serious flaws in the NH provider that should get attention first). And maybe at the end of the day it turns out that the differences between both ways are not worth the confusion. But since both ways come with tradeoffs, maybe it's best to let the user decide. Cheers, Stefan
