Re: Linq project added to core

We do not want to deal with Sql String directly if we can avoid it.That is
why I outlined the hierarchy. We need it. That would let us deal with the
queries in a higher form than string manipulations.

On Wed, Aug 13, 2008 at 8:02 AM, Will Shaver <[email protected]> wrote:

> It looks like Chad Lee added the NHibernate.Linq project and
> NHibernate.Linq.Test projects to the vs2008 solution. Cool.
>
> I spent a few hours tonight going over Linq to NH project and Reflecting
> over Linq to SQL. (What a mess that is.)
>
> If none of you have read this article here:
>
> http://blogs.msdn.com/mattwar/archive/2007/07/30/linq-building-an-iqueryable-provider-part-i.aspx
>
> It seems like a good place to start learning linq.
>
> So the current implementation of linq to NH (contrib) appears to do this:
> (please correct if I'm wrong)
>
> NHibernateQueryProvider->Execute(Expression)
>  //clean expression, translate nodes to NHibernateExpression type where
> needed
>  //visit all expression creating and appending to an ICriteria for each
> part of the query.
>  //execute the ICriteria
>
> Easy enough. We're doing something a bit more complicated this time
> around...
>
>
> NHibernateQueryProvider-> Execute(Expression expression)
>    //clean expression tree, translate nodes to NHibernateExpression type
> where needed. ***
>    //this translation is done by consulting the using the SessionFactory
> for metadata on each item in the expression
>
> option1:
>    //Translate NHExpression to SqlString here?
>    //Pass SqlString to Dialect for translation  (Things like
> factory.Dialect.GetLimitString(sql string))
>
> option2:
>   //Pass NHExpression to the Dialect for limit strings ect,
> public virtual SqlString GetLimitString(SqlString querySqlString, boolhasOffset)
>   becomes
> public virtual NHibernateExpression ProcessLimitString(NHibernateExpression
> expression)
> Which our translator calls to add in that dialect's specific limit string
> and other quirks.
>
>   //Then take the SqlString and process into entities and return as done in
> Loader... Or put processing of the NHibernateExpression in Loader?
>
> Let me know what you folks think.
>
> ***Linq To SQL appears to translate to a different tree type that is not
> inherited from Expression, but contains an Expression property. Perhaps
> there is a good reason for this? Review SqlNode in
> System.Data.Linq.SqlClient via Reflector. Ironically they also have a direct
> copy and paste of the internal marked ExpressionVisitor class in here as
> well...
>
>  -Will
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Nhibernate-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nhibernate-development
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Nhibernate-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nhibernate-development