NHibernate.Linq is a Linq provider for NHibernate 2.0.1 GA. It processes Linq expressions using NHibernate's Criteria API. This release is meant as a stopgap release pending an implementation not reliant on the Criteria API. Most queries are supported with the exception of the following:
- Group Joins - Subqueries in select clause
For a more complete list of unsupported queries, you can look at the skipped test cases in the source distribution.
do you know if its possible to get this to work with the NH trunk? or
is it impossible? I tried compiling a version against it last week
but I had a lot of bother getting things to work. Is there any strict
technical reason why it shouldn't work?
thanks,
Kev
On Jan 15, 9:53 pm, Chad Lee <chadl...@gmail.com> wrote:
> NHibernate.Linq is a Linq provider for NHibernate 2.0.1 GA. It processes
> Linq expressions using NHibernate's Criteria API. This release is meant as
> a stopgap release pending an implementation not reliant on the Criteria
> API. Most queries are supported with the exception of the following:
> - Group Joins
> - Subqueries in select clause
> For a more complete list of unsupported queries, you can look at the skipped
> test cases in the source distribution.
> NHibernate.Linq is a Linq provider for NHibernate 2.0.1 GA. It processes
> Linq expressions using NHibernate's Criteria API. This release is meant as
> a stopgap release pending an implementation not reliant on the Criteria
> API. Most queries are supported with the exception of the following:
> - Group Joins
> - Subqueries in select clause
> For a more complete list of unsupported queries, you can look at the skipped
> test cases in the source distribution.
NH.Linq was working with the trunk up until the previous revision. It
was necessary to compile against NH GA for release. If you want to
build NH.Linq from the NH trunk, you can just update to r695 of
NHContrib which is the previous revision of NH.Linq which compiles
against trunk.
On Jan 15, 6:43 pm, reach4thelasers <kev.m.mul...@googlemail.com>
wrote:
> do you know if its possible to get this to work with the NH trunk? or
> is it impossible? I tried compiling a version against it last week
> but I had a lot of bother getting things to work. Is there any strict
> technical reason why it shouldn't work?
> thanks,
> Kev
> On Jan 15, 9:53 pm, Chad Lee <chadl...@gmail.com> wrote:
> > NHibernate.Linq is a Linq provider for NHibernate 2.0.1 GA. It processes
> > Linq expressions using NHibernate's Criteria API. This release is meant as
> > a stopgap release pending an implementation not reliant on the Criteria
> > API. Most queries are supported with the exception of the following:
> > - Group Joins
> > - Subqueries in select clause
> > For a more complete list of unsupported queries, you can look at the skipped
> > test cases in the source distribution.
> NH.Linq was working with the trunk up until the previous revision. It
> was necessary to compile against NH GA for release. If you want to
> build NH.Linq from the NH trunk, you can just update to r695 of
> NHContrib which is the previous revision of NH.Linq which compiles
> against trunk.
> On Jan 15, 6:43 pm, reach4thelasers <kev.m.mul...@googlemail.com>
> wrote:
> > Hi Chad,
> > do you know if its possible to get this to work with the NH trunk? or
> > is it impossible? I tried compiling a version against it last week
> > but I had a lot of bother getting things to work. Is there any strict
> > technical reason why it shouldn't work?
> > thanks,
> > Kev
> > On Jan 15, 9:53 pm, Chad Lee <chadl...@gmail.com> wrote:
> > > NHibernate.Linq is a Linq provider for NHibernate 2.0.1 GA. It processes
> > > Linq expressions using NHibernate's Criteria API. This release is meant as
> > > a stopgap release pending an implementation not reliant on the Criteria
> > > API. Most queries are supported with the exception of the following:
> > > - Group Joins
> > > - Subqueries in select clause
> > > For a more complete list of unsupported queries, you can look at the skipped
> > > test cases in the source distribution.
> NHibernate.Linq is a Linq provider for NHibernate 2.0.1 GA. It processes
> Linq expressions using NHibernate's Criteria API. This release is meant as
> a stopgap release pending an implementation not reliant on the Criteria
> API. Most queries are supported with the exception of the following:
> - Group Joins
> - Subqueries in select clause
> For a more complete list of unsupported queries, you can look at the skipped
> test cases in the source distribution.
@ Ed C.
Definitely go with this provider instead. The version I posted at
slagd was just a quick patch so users could keep using linq. This one
is more mature.
On Jan 16, 2:31 pm, "Ed C." <defeated...@gmail.com> wrote:
> On Jan 15, 4:53 pm, Chad Lee <chadl...@gmail.com> wrote:
> > NHibernate.Linq is a Linq provider for NHibernate 2.0.1 GA. It processes
> > Linq expressions using NHibernate's Criteria API. This release is meant as
> > a stopgap release pending an implementation not reliant on the Criteria
> > API. Most queries are supported with the exception of the following:
> > - Group Joins
> > - Subqueries in select clause
> > For a more complete list of unsupported queries, you can look at the skipped
> > test cases in the source distribution.
I've just gotten r695 but when I try to build NHibernate.Linq I get
two errors:
Error 1 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
implement interface member 'NHibernate.ICriteria.Future<T>()' C:
\Projects\stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src
\NHibernate.Linq\Util\DetachedCriteriaAdapter.cs 19 15 NHibernate.Linq
Error 2 The type or namespace name 'Dynamic' does not exist in the
namespace 'System.Linq' (are you missing an assembly reference?) C:
\Projects\stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src
\NHibernate.Linq.Tests\DynamicQueryTests.cs 3 19 NHibernate.Linq.Tests
Sorry to post again but when I upgrade to the current version of
NHibernate Contrib the errors I get when building against the latest
version of NHibernate from the trunk are:
Error 1 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
implement interface member 'System.ICloneable.Clone()' C:\Projects
\stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src\NHibernate.Linq
\Util\DetachedCriteriaAdapter.cs 19 15 NHibernate.Linq
Error 2 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
implement interface member
'NHibernate.ICriteria.GetRootEntityTypeIfAvailable()' C:\Projects\stack
\NHibernateCOntrib\trunk\src\NHibernate.Linq\src\NHibernate.Linq\Util
\DetachedCriteriaAdapter.cs 19 15 NHibernate.Linq
Error 3 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
implement interface member 'NHibernate.ICriteria.ClearOrders()' C:
\Projects\stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src
\NHibernate.Linq\Util\DetachedCriteriaAdapter.cs 19 15 NHibernate.Linq
Error 4 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
implement interface member 'NHibernate.ICriteria.Future<T>()' C:
\Projects\stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src
\NHibernate.Linq\Util\DetachedCriteriaAdapter.cs 19 15 NHibernate.Linq
Error 5 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
implement interface member 'NHibernate.ICriteria.SetFlushMode
(NHibernate.FlushMode)' C:\Projects\stack\NHibernateCOntrib\trunk\src
\NHibernate.Linq\src\NHibernate.Linq\Util\DetachedCriteriaAdapter.cs
19 15 NHibernate.Linq
Error 6 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
implement interface member 'NHibernate.ICriteria.SetComment(string)' C:
\Projects\stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src
\NHibernate.Linq\Util\DetachedCriteriaAdapter.cs 19 15 NHibernate.Linq
Error 7 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
implement interface member 'NHibernate.ICriteria.SetFetchSize(int)' C:
\Projects\stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src
\NHibernate.Linq\Util\DetachedCriteriaAdapter.cs 19 15 NHibernate.Linq
rev695 made it work against current trunk, except the fact that Future<T>
implementation for ICriteria. I implemented it and throw an exception, then
it built.
On Wed, Jan 21, 2009 at 10:58 AM, Colin Jack <colin.j...@gmail.com> wrote:
> Sorry to post again but when I upgrade to the current version of
> NHibernate Contrib the errors I get when building against the latest
> version of NHibernate from the trunk are:
> Error 1 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
> implement interface member 'System.ICloneable.Clone()' C:\Projects
> \stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src\NHibernate.Linq
> \Util\DetachedCriteriaAdapter.cs 19 15 NHibernate.Linq
> Error 2 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
> implement interface member
> 'NHibernate.ICriteria.GetRootEntityTypeIfAvailable()' C:\Projects\stack
> \NHibernateCOntrib\trunk\src\NHibernate.Linq\src\NHibernate.Linq\Util
> \DetachedCriteriaAdapter.cs 19 15 NHibernate.Linq
> Error 3 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
> implement interface member 'NHibernate.ICriteria.ClearOrders()' C:
> \Projects\stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src
> \NHibernate.Linq\Util\DetachedCriteriaAdapter.cs 19 15
> NHibernate.Linq
> Error 4 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
> implement interface member 'NHibernate.ICriteria.Future<T>()' C:
> \Projects\stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src
> \NHibernate.Linq\Util\DetachedCriteriaAdapter.cs 19 15
> NHibernate.Linq
> Error 5 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
> implement interface member 'NHibernate.ICriteria.SetFlushMode
> (NHibernate.FlushMode)' C:\Projects\stack\NHibernateCOntrib\trunk\src
> \NHibernate.Linq\src\NHibernate.Linq\Util\DetachedCriteriaAdapter.cs
> 19 15 NHibernate.Linq
> Error 6 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
> implement interface member 'NHibernate.ICriteria.SetComment(string)' C:
> \Projects\stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src
> \NHibernate.Linq\Util\DetachedCriteriaAdapter.cs 19 15
> NHibernate.Linq
> Error 7 'NHibernate.Linq.Util.DetachedCriteriaAdapter' does not
> implement interface member 'NHibernate.ICriteria.SetFetchSize(int)' C:
> \Projects\stack\NHibernateCOntrib\trunk\src\NHibernate.Linq\src
> \NHibernate.Linq\Util\DetachedCriteriaAdapter.cs 19 15
> NHibernate.Linq
I realize this is something of a silly question (an alpha is an alpha,
right?) but is this release usable for production? I recently joined
an enterprise-scale project and am evaluating ORM implementations,
with NHibernate and Entity Framework on the short-list. To give me my
first experience with NHibernate to best evaluate it I'd like to
implement a very small production project using NHibernate.Linq. (A
simple web service to be used by external entities meaning we don't
want to be embarrassed by breakage.) Current best estimate is to
implement the very small project within a month, a medium project by
the middle of July, and everything else in an 8-16 month time frame.
Will NH.Linq be up to heavy-duty use in this time frame?
Research into the Entity Framework indicates the desired feature set
won't be available until at least after upcoming 2010 release, and
frankly we can't wait that long. I'm hoping NHibernate can provide
what we're looking for in a timelier manner?
Any thoughts, suggestions, or comments regarding the situation? If
you've used it what has your experience been with NH.Linq?
Thanks so much for your help!
Drew
On Jan 15, 2:53 pm, Chad Lee <chadl...@gmail.com> wrote:
> NHibernate.Linq is a Linq provider for NHibernate 2.0.1 GA. It processes
> Linq expressions using NHibernate's Criteria API. This release is meant as
> a stopgap release pending an implementation not reliant on the Criteria
> API. Most queries are supported with the exception of the following:
> - Group Joins
> - Subqueries in select clause
> For a more complete list of unsupported queries, you can look at the skipped
> test cases in the source distribution.
Personally, I'd design my app to take account of the Alpha nature. If
EF isn't going to be ready then you don't have a lot of choice. No
other freeware solution comes close to NH in my opinion.
In our company I've designed the apps so I have a formal repository
that implements an interface in the domain later. This interface
defines that has methods you can call but the repository implements
them. This reverse dependency is wired together via an IoC product
such as Spring.NET or Unity.
Therefore I have a choice in the repository how I implement the method
- I can use Linq-NH, which works in 70-80% of cases or, where it gets
complicated I can shift to HQL. The domain layer doesn't care how the
repository does it.
Although it isn't "pure" and I don't really like it, I do expose a an
IQuerable<T> Query property in the repository for those simple ad-hoc
queries that Linq excels at, so I don't need a special method for
every single simple thing I need to do.
I also make sure my developers know Linq-NH isn't a fully featured
Linq implementation (e.g. I can't get it to do joins) but as least I
have an architecutre in place to work around any issues that crop up.
I also have an architecure to swap to EF if I need to in 2010 / 2012
but I expect with NH 3.0 Linq will be fully featured and I won't
really need to.
> Personally, I'd design my app to take account of the Alpha nature. If
> EF isn't going to be ready then you don't have a lot of choice. No
> other freeware solution comes close to NH in my opinion.
> In our company I've designed the apps so I have a formal repository
> that implements an interface in the domain later. This interface
> defines that has methods you can call but the repository implements
> them. This reverse dependency is wired together via an IoC product
> such as Spring.NET or Unity.
> Therefore I have a choice in the repository how I implement the method
> - I can use Linq-NH, which works in 70-80% of cases or, where it gets
> complicated I can shift to HQL. The domain layer doesn't care how the
> repository does it.
> Although it isn't "pure" and I don't really like it, I do expose a an
> IQuerable<T> Query property in the repository for those simple ad-hoc
> queries that Linq excels at, so I don't need a special method for
> every single simple thing I need to do.
> I also make sure my developers know Linq-NH isn't a fully featured
> Linq implementation (e.g. I can't get it to do joins) but as least I
> have an architecutre in place to work around any issues that crop up.
> I also have an architecure to swap to EF if I need to in 2010 / 2012
> but I expect with NH 3.0 Linq will be fully featured and I won't
> really need to.
Good luck, NH is a great product but its a big learning curve from
scratch. My first experience of it was sorting out another (fired)
architects mistakes so I've been through the fire with it.
Look at Jimmy Nielson - Domain Driven Design; a good book that really
makes you think about persistence ignorance. If you enforce neutrality
in the domain layer (i.e. be ultra strict about not allowing NH to
bleed into it) then you keep your options open for the future. IMO
anyway.
|
