+1 for option 3 as well. I think if the NH team is serious about this effort, then we should pursue the path that leads to the greatest long-term benefit to the overall codebase in re: future other extensibility points, etc. Option 3, fully articulating the query as an AST and using that as the basis for translating into subsequent query implementations, is clearly the approach that is the most open, future-looking, and flexible vector IMO.
Its also the one that it seems to me will leave the project in the best position for others to complete the NHLINQ implementation should three months prove insufficient for the provided dev resource (Steve?) to entirely complete the effort -- a consideration that I think is worth ensuring we have a strategy for dealing with (e.g., if 'all' that comes from the three months is a completley solid AST engine, this would at least give others a strong basis upon which to complete the LINQ implementation atop it). Since the commitment is 'three man-months' rather than 'working implementation of NHLINQ' this seems a reasonable potential consideration to me. Bottom line: I think if we are going to proceed, we should proceed in the 'right' way even if that way is more complex, time-consuming, etc. The ability to borrow from H3 seems a strong additional benefit to this approach too. -Steve B. (the other Steve) On Sat, Jan 17, 2009 at 8:49 AM, Tuna Toksöz <[email protected]> wrote: > +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 >> > >
