Ayende @ Rahien

Frank Quednau commented on Developing Linq to NHibernate

Tue, 02 Dec 2008 10:04:56 GMT

No luck from here. Customer is downsizing and I won't be there for some foreseeable time in 2009. It doesn't look like they are interested in any sponsoring

Rainer Schuster commented on Developing Linq to NHibernate

Thu, 13 Nov 2008 13:37:35 GMT

How about Matt Warrens code-base ( [blogs.msdn.com/.../...ryable-provider-part-xi.aspx](http://blogs.msdn.com/mattwar/archive/2008/07/14/linq-building-an-iqueryable-provider-part-xi.aspx)) that Rob is using in his Sub-Sonic 3.0 (previewed last week on his blog)?

Martin Nyborg commented on Developing Linq to NHibernate

Mon, 10 Nov 2008 21:10:41 GMT

Any final words?

Martin Nyborg commented on Developing Linq to NHibernate

Thu, 06 Nov 2008 20:38:31 GMT

Yes the DbLinq OS project looks promising take a look at it [http://code2code.net/DB_Linq/](http://code2code.net/DB_Linq/) And I am also willing to donate 200$ Why not send Scot Guthrie a letter maybe just maybe he can see the value in helping to support the nerds favorite tool. I have a lot of faith in him.

Jay commented on Developing Linq to NHibernate

Thu, 06 Nov 2008 20:17:29 GMT

If you begin accepting individual donations or pledges for future donations, I would be interested.

Steve Wagner commented on Developing Linq to NHibernate

Thu, 06 Nov 2008 16:48:20 GMT

@Ayende: There is an OS project which Miguel de Icaza introduced in his blog [http://tirania.org/blog/archive/2008/Oct-01-2.html](http://tirania.org/blog/archive/2008/Oct-01-2.html) they trying to create an Linq to DB provider. May it can help.

Roderik Steenbergen commented on Developing Linq to NHibernate

Tue, 04 Nov 2008 20:37:14 GMT

A very interesting discussion. I think NHibernate (or any OR mapper for that matter) needs a complete LINQ provider to maintain a serious position in the .NET world. I wish I had (or would be backed by) a big enough company to spend a good chunk of money on this since NHibernate is such a productive, and free tool and LINQ adaptivity would take it to the next level, not in the least for integrating with other MS technologies. To all the LINQ nah-sayers in this thread and to explain previous statement: LINQ is way more than just a mechanism for querying a relational store. LINQ is a standardized way of querying any structured data as long as a provider is available. It's an abstract concept implemented as a first class language construct. IMHO this goes beyond just compile time checking, which is already by itself a huge benefit. Take a look at this video, it explains a lot of the concept: [channel9.msdn.com/.../Erik-Meijer-and-Bart-De-S...](http://channel9.msdn.com/shows/Going+Deep/Erik-Meijer-and-Bart-De-Smet-LINQ-to-Anything/) More pragmatic, microsoft has adapted LINQ in a great deal of the upcoming products that I personally would like to use (Astoria, Dynamic Data etc.) and will probably keep doing so in the near future. Since we're still all on the microsoft train, I think we should try to stay at least aboard the behemoth, instead of trying to totally take a sidetrack. (excuse the weak metaphore) Good luck with the undertaking! P.S. Personally, I would also be willing to donate a smaller amount of money (100$-200$) for an operation like this although I do realize you need some big sponsors.

Daniel commented on Developing Linq to NHibernate

Tue, 04 Nov 2008 18:09:28 GMT

Ayende, Perhaps you can use [http://fundable.org](http://fundable.org) to set up an individual-level contribution pledge drive. That way individuals can still contribute what they can, but you don't need to commit to starting any work until you reach the level of cash-flow you had in mind to make it happen. It might turn out better than you expect.

Cassio Tavares commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 22:13:47 GMT

I can't understand why you don't like linq. With Linq to NHibernate I don't need to do specific DAO functions that will be called by a single point anymore. And of course there are other benefits like Frans has pointed.

Scott White commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 20:09:45 GMT

I think it's a great idea. I'm not a big fan of Linq however. I still like criteria expressions that NHibernate provides better than Linq.

Frans Bouma commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 17:21:13 GMT

@fred: sent :)

Fred commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 16:43:20 GMT

@Frans Bouma --> f.ba@free.fr Very interested, Fred.

Frans Bouma commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 16:26:12 GMT

@Fred If you're interested, I had a large reply typed, but the comment system didn't accept it (perhaps a good thing considering it is indeed off-topic), so if you want to read it, contact me off-list. @Ayende: I do recall that on the codeproject, there's some linq to sql clone code written by a guy from Kenia which converts to SQL as well, and although the code is hard to follow (no comments, if I'm not mistaken), he has written quite a lot of handlers for a lot of constructs. See: [www.codeproject.com/.../MemberArticles.aspx](http://www.codeproject.com/script/Articles/MemberArticles.aspx?amid=4829645) He borrowed a lot from Matt Warren's articles, so it might also be a good start for you.

Fred commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 16:15:15 GMT

+1 You're right. Sorry about that.

Frans Bouma commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 16:14:26 GMT

@Gengis: "@Frans : with HQL you can override the 'lazy' behavior to avoid n+1 select if session is open ('queries generated behind the scenes' as you say) or LazyInitException if it's not. 'join fetch' synthax is crucial in hql to avoid theses pitfalls and should be available with another query language (linq in this case)." I think that's easily addable with an extension method of IQueryable, which simply builds a MethodCall expression to the method so it's inside the expression tree. The handler can then adjust the query element according to the parameters passed to that extension method. One thing which might be a little problematic is that an extension method of IQueryable can be called everywhere an IQueryable is used, but at the same time it might not make sense to have that particular extension method at that spot, so documentation is required in these cases. We have a similar extension for specifying prefetch paths in linq queries (so fetch orders, and all their related customers into that graph in 1 linq query using 2 SQL queries): the extension method is callable from everywhere, but really makes sense in the most outer IQueryable, otherwise it will be wrapped inside a derived table for example which doesn't need paths. Not everything is great with Linq ;) (not by far)

Stephen commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 16:12:35 GMT

Jesus fred keep it in the ring, not this blog - its really frustrating to read blogs that get side tracked on to something thats completely unimportant to the original topic..

Fred commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 15:56:33 GMT

@gengis --> + 1 Exactly my opinion.

Fred commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 15:54:01 GMT

@alwin Agree. Except on the first point, but mainly due to critical aspect : we are forced to reduce side effects of new entities implementation, since our real risk and concerns are on the business layer, so we try to keep a "clean" entities management. "Everything the compiler can do for me instead of me thinking about it is great IMO. Compiler errors instead of runtime errors = time saved for me"; probably I would answer 'Compiler errors instead of runtime errors = layers design problems and time wasting', but it is only true in my context. I easily understand that alone on a project, first solution is far better and flexible. And I'm not negative to Frans, I can understand that he need to "buzz" arround LLBL, it's business after all. Even if I did not get satisfaction with LLBL, Frans has still a huge and very valuable expertise on many subjects.

alwin commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 15:25:10 GMT

"And i forgot to mention, I (my company exactly) is one of your client. We replaced LLBL with Nhibernate due to a lack of clear answers from your side. So yes, I'm quite frustrated." This explains why you're so negative to Frans. "Well I guess that's one of your "best practice" a developper should know before modifying the domain where it changes; and not implement new domain entities and just "debug" errors...Ok, it gives you a bit more flexibility, but certainely not quality." Everything the compiler can do for me instead of me thinking about it is great IMO. Compiler errors instead of runtime errors = time saved for me. Maybe in your "hundred of k€" system, renaming a entity property goes through several layers of management and risk assessment. But don't forget that for every 100.000 euro system, there are hundreds of small apps where the developer has the freedom and the need to safe and simply rename things when he wants to.

Fred commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 15:06:22 GMT

@Frans And i forgot to mention, I (my company exactly) is one of your client. We replaced LLBL with Nhibernate due to a lack of clear answers from your side. So yes, I'm quite frustrated. But no matter, we don't need it anymore.

Fred commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 15:03:07 GMT

Just a reaction of someone working in the software industry : " Linq has a couple of benefits, one being that it's compiler checked. " Well I guess that's one of your "best practice" a developper should know before modifying the domain where it changes; and not implement new domain entities and just "debug" errors...Ok, it gives you a bit more flexibility, but certainely not quality. "So if you rename an entity's class, the compiler will show you where the queries break. Sure, your system of course never runs into runtime errors with wrongly named entities, fields etc. in HSQL strings, but a lot of others do." Sorry for the users, but refers to previous. It's called specification and domain management. I'm not a method or management addict, but what you point is more related to development process than Linq added value.... "Another big advantage is that an IQueryable interface is supported by more and more 3rd party control vendors. So databinding with custom filtering/sorting on the DB without 1 line of code. " Yes, still thinking in Client server, using domain in UI... What a great software engineering example... what about using services ? what about proxies ? what about authorisation tokens ? What about lock ? What about 2nd level cache ? What about track changing ? ...Great added value, no scalability, no control, but quick and dirty development. I point out that for professional development, (I mean when you have a lot of clients spending hundred of k€ in your system a year); you can't live with "out of the box" products. First, it is a great mistake, due at least to SLA / SSD Second, what happens if you 3rd party vendors stop support ?

Gengis commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 14:06:47 GMT

@Frans : with HQL you can override the 'lazy' behavior to avoid n+1 select if session is open ('queries generated behind the scenes' as you say) or LazyInitException if it's not. 'join fetch' synthax is crucial in hql to avoid theses pitfalls and should be available with another query language (linq in this case).

Fred commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 14:06:09 GMT

@Frans "So, my queries are what, slower? I doubt it." No , but not really user friendly. That's why I understand that supporting Linq is a good option on a product management point of view. ResultsetFields fields = new ResultsetFields(2); fields.DefineField(CustomerFields.ContactName, 0); fields.DefineField(new EntityField2("Total", (OrderDetailsFields.Quantity * OrderDetailsFields.UnitPrice), AggregateFunction.Sum), 1); RelationPredicateBucket filter = new RelationPredicateBucket(); filter.Relations.Add(CustomerEntity.Relations.OrderEntityUsingCustomerId); filter.Relations.Add(OrderEntity.Relations.OrderDetailsEntityUsingOrderId); GroupByCollection groupBy = new GroupByCollection(); groupBy.Add(fields[0]); DataTable table = new DataTable(); using(DataAccessAdapter adapter = new DataAccessAdapter()) { adapter.FetchTypedList(fields, table, filter, 0, null, true, groupBy); } ....A developper bliss..... or this // construct filter, which will span multiple entities. RelationPredicateBucket filterBucket = new RelationPredicateBucket(); // Start with the entity you want to retrieve... filterBucket.Relations.Add(CustomersEntity.Relations.OrdersEntityUsingCustomerId); filterBucket.Relations.Add(OrdersEntity.Relations.OrderDetailsEntityUsingOrderId); filterBucket.Relations.Add(OrderDetailsEntity.Relations.ProductsEntityUsingProductId); // create the predicate 'Product.ProductId == value', we will fill in the value later. filterBucket.PredicateExpression.Add(ProductsFields.ProductId == productId); EntityCollection customers = new EntityCollection(new CustomersEntityFactory()); using (DataAccessAdapter adapter = new DataAccessAdapter()) { // fetch the customers with the filter specified. adapter.FetchEntityCollection(customers, filterBucket); } ....would require 3 lines of HSQL. But that's another story I guess...

Ayende Rahien commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 13:59:09 GMT

Stefan, I fully intend to make use of existing linq provider logic. I thought about starting from the DB Linq code base, but I would be really interested to see what re-linq can do for us. As for NH features you want, just suggest them, and we will see if they make sense in the context of NH or not. Worst case scenario, we can probably open extension points that will allow you to do so.

Stefan Wenig commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 13:53:34 GMT

Hi Ayende, since we’re not users of NHibernate, there’s no money going to come from us for direct contributions to NH*). But we have our own OSS story with our re-motion framework (I contacted you about this last year), and one part of it is a component we dubbed re-linq. It’s a simple transformation of the mess that a from … select query expression generates in terms of IQueriable method calls, back to a simple from … select object model. The resulting query model is logically very close to that of SQL, which makes producing a LINQ provider much easier. Even for full blown nested joins, groups etc. (Don’t know how close it is to HQL though.) This includes transformations of transparent identifier translations (see c# 3.0 spec 26.7.1.9) back to a logical model where sub-expressions can just reference parameters defined in other parts, a major PITA when transforming expression trees to SQL. Work on re-linq is finished, it’s currently being used in our own ORM (called re-store; yes, there’s a pattern here). It's 100% TDD and ready to use, so it should really save everyone who wants to code a LINQ provider some serious time. The query model is currently limited to query expressions that C# can produce (i.e. we do not support any and all arbitrary calls to IQueriable that bypass the from … select syntax). We’ve been thinking about adding intermediate transformation steps, where anything could be thrown at re-linq and be simplified to a certain point, much like Frans Bouma had shown in his blog post series, just OSS. There are no current plans to actually start work on this, though. You’re free to use re-linq, it’s LGPL. Also, if there’s anything you would like to develop within the boundaries of re-linq, i.e. something that would make it better not only for NH but also for any other re-linq-based provider, there might be a chance for me to have it funded. For instance, some transformations can be done in the intermediate model we’re producing. Take the customer/country example from Frans, there could be transformations within LINQ that “normalize” everything into either form. Making implicit joins from acessing nested properties explicit would be another. (However, the main idea is just to reduce the 2 to 3 months you’re estimating, or whatever it really takes.) Please just answer if you’re interested, I can follow up with more information (including repository access, which is not yet public because we have not worked out if and how we could have one common license header when the code is split in LGPL, GPL and AGPL parts, but that should be a matter of days from now.) Stefan *) Actually, there could be some features we'd like to see in NH too, but I doubt they would be of any interest to most NH users.

Ayende Rahien commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 13:33:16 GMT

Frans & Fred, Just to point out, I really appreciate Frans' comments here. It is always good to gain knowledge from the experience of others.

Frans Bouma commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 13:28:08 GMT

@Fred "Well I've benchmarked both and it happens that LLBL queries are far from being HSQL. (No "cold shoulder" here, just a fact)" So, my queries are what, slower? I doubt it. "Considering the mindset, between the two competitors, I agree that expression trees are tricky, however, nhibernate already have a similar abstraction querying language --> HSQL." No. HSQL isn't the same as linq. That's the whole point of it being difficult to support in a provider. For example: var q = from c in ctx.Customer group c by c.Country into g select g; That's a hierarchical projection, where you get IGrouping elements, which each are enumerable. It's things like that which makes Linq different from the default select ... from ... where ... query API systems. "In this case, you should also stop giving "advices" to your competitor, but we both know that you're just doing some marketing stuffs." Frustrated, Fred? Why can't I give, as a developer to another developer, give honest advice without giving up a large piece of what I worked very hard for? Did it ever occured to you that one could just be friendly? Apparently not, because there are strings attached and the friendlyness is just a trick to get more money, right? When I discuss Linq provider tech with a MS developer who worked on it, do you think they'll say to me "you won't get advice from us" ? No not at all, they'll help you. But they won't give you their sourcecode. I hope you'll see the analogy. "My point is that Linq is only "sexy" and you can have intellisense.:" Again, you don't show a lot of understanding of the material here, Fred. :) Linq has a couple of benefits, one being that it's compiler checked. So if you rename an entity's class, the compiler will show you where the queries break. Sure, your system of course never runs into runtime errors with wrongly named entities, fields etc. in HSQL strings, but a lot of others do. Another big advantage is that an IQueryable interface is supported by more and more 3rd party control vendors. So databinding with custom filtering/sorting on the DB without 1 line of code. Further, linq is standard, so every person who has got a linq to sql course can start with linq and another o/r mapper. With HSQL, that's not the case, despite the fact that it looks simple in a lot of cases . "Ok; but what about controling lazy loading through linq ? And that's a real issue" What has lazy loading to do with Linq? Linq is used to allow the developer to write queries. Lazy loading is a mechanism where queries are generated behind the scenes, so the developer isn't doing anything, so linq is not involved.

Fred commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 12:51:25 GMT

@Stephen Well if it doesn't work it doesn't work. I did not really understand "debugging" HSQL vs Linq. HSQL is perhaps not perfect, ok, but most of people forget about nhibernate that you can get the sources and add some checkpoints to track you development (not really happening with Linq to SQL f.e) Actually I have more than 800 entities, with a very strong business object layer, and I must admit that I never experienced any issues with HSQL. Some times, it is even so simple that it is difficult to believe. And that's the other strong point of Nhibernate, it is not a black box with expert explaining you what you need. My point is that Linq is only "sexy" and you can have intellisense. Ok; but what about controling lazy loading through linq ? And that's a real issue

Stephen commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 11:11:41 GMT

Speaking naively here, shouldn't you first expand the query into a full form and then map against a fully resolved tree? this way your mapping doesn't have to deal with the fact that this and that should both come out the same? I'm also not sure what a 100% sure mapper means, linq to sql isn't perfect yet theres a lot of people using it.. I'm sure linq to entities isn't perfect either.. is HSQL perfect ? I doubt it - I've not used it much.. but I certainly prefer to write LINQ than ugly ass runtime debugged strings.

alwin commented on Developing Linq to NHibernate

Mon, 03 Nov 2008 10:15:20 GMT

@Hammett: What i understood from Ayendes post is that if people will pay him, he (or someone else) can make time. Something like SvnBridge or something. Ayende please correct me if I'm wrong.