+1 for option 3 for the same reason you say. The HQL approach is not very different than Criteria, even though it is stronger in feature.
Being able to port from H3 is really a bonus. Davy the code is in uNhAddins Repository. http://unhaddins.googlecode.com/svn/trunk/ Tuna Toksöz http://tunatoksoz.com Typos included to enhance the readers attention! On Sat, Jan 17, 2009 at 3:46 PM, Davy Brion <[email protected]> wrote: > +1 for option 3 > > do you have access to Fabio's Artorius code? I guess it would be best if > that could be reused instead of having to duplicate Fabio's efforts here. I > have no idea where he hosting that code though... if he's hosting it online > at all. > > > On Sat, Jan 17, 2009 at 2:40 PM, Ayende Rahien <[email protected]> wrote: > >> I am reviewing the possibilities that we have for a robust Linq >> implementation, and it seems like we have several options. >> >> As a reminder, iMeta has granted us a full time developer for 3 months for >> this task, so we have someone that can actually work on this specific task >> full time (which solves the biggest problem that we had so far with this). >> >> Now, as I see this, we actually have two separate issues with NH Linq. The >> first is the actual linq parsing, the second is moving from the expression >> tree to a query. >> >> The first problem is not something that really concerns me. I think that >> we can make use of existing linq providers impl to build our own. Basing >> ourselves on something like IQueryable Toolkit or similar frameworks. >> The second is the more complex issue, and that relates to the thorn in our >> side, HQL AST. >> >> I think that we have 3 main options for NH Linq query building. >> >> 1) build a 3rd way to query the DB, sibling to HQL and Criteria. That >> would be, in my opinion, stupid in the extreme, because of the scope of the >> task and the fact that it would only cause more issues, not less. >> >> 2) take the Linq expression tree and generate HQL out of it, which we will >> then use to perform the actual query. >> This is probably the easiest approach, it would require minimal >> modification from NHibernate and we can get it out the door very quickly. >> This feels hacky, however. >> >> 3) build the HQL AST, port the AST query approach from Hibernate. Base the >> Linq implementation on the AST. >> That is where I _want_ to go. It is the biggest task, but I think that it >> will leave us in a much better position overall. We also have the benefit of >> being able to port the feature (except for the actual parsing) directly from >> Hibernate, making the actual task much easier, and getting the benefits of >> the test cases that they have. >> >> As a bonus, Steve, the developer that we have for this task, has some >> experience with GOLD parser, Which is what Artorius (the latest attempt to >> create the NH HQL AST) is written in. >> >> I would like to get your opinions about where we should go. > > > > > -- > Davy Brion > http://davybrion.com >
