NHibernate HQL AST Parser
Steve from iMeta has been doing a lot of work on the HQL AST Parser. For a long time, that has been a really troublesome pain point for us, since this is a prerequisite for a lot of other features. It is also one of two parts of NHibernate that really need significant refactoring because the way they are built right now make it hard to do stuff (the second being the semantic model for the mapping, which the Fluent NHibernate guys are working on).
Just to give you two features that should make you drool which depends on this work:
- Full Linq implementation
- Set based DML operations on top of the domain model
In true Open Source manner, you can view the work being done right now: http://unhaddins.googlecode.com/svn/trunk, Checkout the ANTRL-HQL project.
This is something that several members of the NHibernate project has tried doing in the past, but the scope of the work is very big, and require full time work for an extended period of time. iMeta has been sponsoring Steve’s work on NHibernate, which make this possible.
I have been going through the code, and I am literally jumping up and down in excitement. It is still very early, but it is already clear that Steve has taken us much farther than before, and it is possible to see the end. The most significant milestone has been reached, and we are currently able to execute ( a very simple ) query and get the results back:
Yes, it also integrates with NH Prof :-)
Comments
Could you explain "Set based DML operations on top of the domain model"?
John,
delete from Rule ar
where ar.Enabled = false
Which will be translated to the correct SQL for the database.
In other words, this is HQL DML
I'm very interested to know what kind of work/refactoring is actually being done on the AST parser. Particularly this part: "The most significant milestone has been reached, and we are currently able to execute ( a very simple ) query and get the results back."
Why does HQL need refactoring to be able to execute that query?
Oh... got bit idea now after reading steve post. NHibernate did not have AST parser. Really excited about linq to NH :)
Giving dialects access to AST would make dialect writing a hell of a lot more flexible. I hope this is considered.
Hi, could you quickly explain in a more detail (w/o linking to previous numerous post) why it is such a problem to make LINQ provider for NHibernate?
simple question, but maybe a hard answer...
There are numerous OR/M frameworks that have LINQ working for couple of months now already (although some of them only partial), actually I am having a hard time finding one which is more "backwards" with LINQ progress that NHibernate is (with exception of Subsonic 3.0, which is complete rewrite so that is ok).
Why do you need an HQL AST parser for LINQ which already gives you an AST? As for set-based DML operations -- is it possible to do them with other NH APIs in current version?
@Andrey,
reading between the lines of Steve's post, it seems that this possibility was considered and discarded.
Bob,
The main difficulty is related to the way we do queries.
NH has several ways for doing that, but no single cohesive way.
That means that a Linq provider for NH needs to work with a query mode, or write our own.
That is problematic, because of the number of features that NH has that needs to play way with Linq.
We could have bolted that on, but that would have caused issues down the road.
NH had a working Linq implementation during the Alpha period, that is not the issue. The issue that what we consider a 1.0 release for Linq support is a high bar to cross, so we weren't wiling to release something that answer only partial need.
Andrey,
The problem is what do you do with the Linq AST?
NH didn't have a good way of translating that to the actual query.
Ok, it seems I have missed the main point -- how the HQL worked all this time without AST? As a person not really familiar with NH, I was sure that it was parsed into some kind of object model (criteria?).
Andrey,
It was translated directly into the query model.
Hibernate has an ANTLR based HQL parser for quite some time, why isn't that work re-used? Or is the HQL that much different?
It's easier to write a Linq to HQL interpreter of expression trees, than it is to write a Linq to Criteria + query specifics system. I think that's the idea behind this AST approach? (i.o.w.: solve some things like derived-table creation on the fly in the HQL AST, so the linq to HQL interpreter is quite simple. ?
Frans,
The ANTLT dialect used by Hibernate is 2.0
2.0 isn't well supported for C#
3.0 is drastically different.
The work that Steve is doing is porting that to .Net
Does adding an AST parser solve the NH -514 issue as well? Is this not the part that was missing in order to support additional "ON" or join filters as well?
Comment preview