What about also having a paypal account so the community can contribute individually as well?

Ian,

Experience shows that this is not a good way of getting significant amounts of money.

There is a reason why I talked about companies, most individuals wouldn't be able to contribute 5,000$ to 10,000$ for this, and those are the sums we are talking about

Next week (12th) I am at my customer again, who is beginning to use NHibernate for its new platform. I'll definitely ask them. Have put task in my mobile.

I think that this is a great idea maybe Microsoft will pay for it :-) to make up for the death of Linq2Sql.

No I also seriously think that NH needs a top notch Linq provider without it, we in the community are going to lose a lot of new "customers".

And I have also failing in love with the IQueryable repository pattern and so have many of the new technology's from Microsoft like ADO .NET Data services and the upcoming Alexandria framework for SilverLight.

I hope that you can pull this off and I wish you good look.

Is there a reason we can't start small and build one feature at a time, OSS style?

I agree with you, some companies could help to contribute. What I would like to know is:

I already seen people relationed to Linq to NHibernate saying that it must be rewritten from scratch. So, what is the problem with te current version? Is it fast? Are we gonna miss any functionality?

I don't know if these companies would like to know that they contributed to a project that will born with any of these problems.

But I am sure if you are proposing something like that is because it will worth every penny.

I am not criticizing the idea. I'm just curious about it.

what is the problem with te current version?

The problem is its ability is restricted with Criteria API which can do very well for most scenarios but not very suitable for a complex Linq expression.

Writing linq-nh from scratch brings other good things: Hql will be translated into expression tree, criteria(backward compatibility) will be translated into expression tree, and even dialect may have something to do with expression. We'll have uniform way of producing SQL.

Do you mean "fund"?

"If you or your company are interested in helping find the Linq for NHibernate project"

pb,

The problem that this is a really big task, and there isn't any single person who is both interested in this and is able to dedicate it the amount of time it deserves.

Yes, we can do it OSS style, but that would take a long while, in my opinion

Shawn,

Thanks, fixed.

Whats the story with JBoss, can they contribute anything, its not like Red Hat didn't bring in 164 Million last quarter?

http://finance.google.com/finance?q=redhat

Are there any usage numbers for NHibernate, even download counts?

Maybe do some gorilla marketing with Blogs, Mail Lists, and Forums and start a bounty at http://www.bountyup.com/

This will at least give you an idea of what kind of funds can be raised.

I know we all can't contribute $10K or $5K but I think there are many devs using NHibernate that would not mind contributing $50 - $100 to get a good version of LINQ.

@Myself... bountyup might be a bad site... It was the first one I hit with a google search and then realized there were only 5 projects in there.

@Ayende, Maybe just some simple commitment form on your blog would be better just to give you an idea of the support you could get.

Our linq provider sourcecode for LLBLGen Pro is relatively o/r mapper agnostic as in: you need a set of factories and the like to make it usable for other o/r mappers. it's not done overnight, but it will take a couple of weeks, tops to port it.

As we're going to support nhibernate as well in v3, we'll try to port our linq provider to nhibernate as well, so people get everything they need. Though it will take a while before that's out (H1 2009)

I think you're very optimistic when you say '3 months' of work, it took me more than 8. It's not the basic stuff that takes the most time, so basic from/where/select queries are fairly easy to support. The main crap starts when you want to support nested groupjoins, joins with where's, group on constant (for devexpress' controls for example) etc. These are things which take more time than you might want to spend on it. The sad thing is: if you don't do that, people will in the end ignore the linq provider as it will break on unexpected moments.

Adam,

RedHat / JBoss has dedicated exactly 0 resources for NHibernate in the last two years, and I see no reason to think that this will change.

Frans,

A major difference between our approaches is that you want to give them 100% out of the box.

I, on the other hand, want to build the foundation and the building blocks, get 80% of the way there, and then lazily work on the weird conditions from there.

Oren: still, I think getting 80% done is more work than 3 months. It's also a gamble what you want to count under that 80% and what you will classify as 'edge case'. It really takes a group of users to see what is common usage and what is edge case: for a user, it might be logical to do it using method A, but he should use method B because A is edge case and B is logical. A typical example of that is this:

var q = from c in ctx.Customer

        where c.Country == "USA"

        from o in c.Orders

        select o;

vs:

var q = from c in ctx.Customer

        where c.Country=="USA"

        join o in ctx.Order on c.CustomerId equals o.CustomerId into co

       from order in co.DefaultIfEmpty()

       select order;

they should result in the same SQL. the expression trees are very different, and both require a lot of work to get right. For example, the where clause has to be extracted and re-located inside the tree, the nested from clauses form a relation but you can't see that directly so you have to alter a relation you've already seen later on.

Typically, a linq provider writer will focus on query 2 first, as that's close to the syntax, and you want to cover at least the elements in the syntax. However a lot of users find the first query much easier to write. Is the first query an edge case? :)

I agree that one should focus on basic elements first, but with this, it's hard to determine what that 80% is of what a developer would need.

hi ayende,

I am willing to give 20 hrs a week for the project

thanking you

balaji.g

Does it need to be money? What about time?

In responds to Frans Bouma suggestion.

I think that you Oren at least could have started a conversation with Frans instead of giving him the cold shoulder.

I know that the mindset of LLBLGen pro and NH is very different but you got to admit that LLBLgen is an excellent tool if the database is king.

Talk with him about the LINQ provider

Martin, I personally feel that if Frans is a nice guy that he is, then he should email Oren privately instead of jumping on this thread.

@firefly: Well, our linq provider is of course a unique selling point of our commercial application, so I'm not going to give away the sourcecode of that to a competitor. All I wanted to do here is to explain to Oren to be more realistic with this project so he won't run into unexpected surprises.

@Martin: Thanks for the support :), though I don't think Oren was giving me a cold shoulder ;). He should do with my advice what he thinks he should do, that's up to him. Though I'm not going to give away code which I've worked on for 8 months straight for nothing. I don't mind helping out a fellow software engineer, no problem with that, but it ends somewhere. As I said above, I just wanted to warn Oren about the scale/complexity of these kind of projects, it's not doable in 2-3 months, no way.

Well I've benchmarked both and it happens that LLBL queries are far from being HSQL. (No "cold shoulder" here, just a fact)

So I'm not sure that Linq could be a "selling point" of Nhibernate.

Considering the mindset, between the two competitors, I agree that expression trees are tricky, however, nhibernate already have a similar abstraction querying language --> HSQL.

On the other hand, I think that large scale enterprise application have others need and objective that implementing Linq.

You would be for example very surprised of the amount of sensitive application are running at Merril Lynch with Nhibernate. Even if Merril Lynch is not today an excellent example.

For doing something meaningfull with nhibernate, I've no doubt Oren will suceed in doing something very smart. and publish a usefull source code.

"Well, our linq provider is of course a unique selling point of our commercial application, so I'm not going to give away the sourcecode of that to a competitor" --> In this case, you should also stop giving "advices" to your competitor, but we both know that you're just doing some marketing stuffs.

@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.

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.

@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

@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 <string,> 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.

Frans & Fred,

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

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.

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.

@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...

@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).

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 ?

@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.

"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.

@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.

@gengis

--> + 1

Exactly my opinion.

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..

@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)

+1 You're right. Sorry about that.

@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

He borrowed a lot from Matt Warren's articles, so it might also be a good start for you.

@Frans Bouma --> f.ba@free.fr

Very interested,

Fred.

@fred: sent :)

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.

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.

Ayende,

Perhaps you can use 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.

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...

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.

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

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

Yes the DbLinq OS project looks promising take a look at it

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.

Any final words?

How about Matt Warrens code-base ( blogs.msdn.com/.../...ryable-provider-part-xi.aspx) that Rob is using in his Sub-Sonic 3.0 (previewed last week on his blog)?

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