Linq update

About a week ago NHibernate 2.0.1GA was released, but I haven’t had a chance to compile NHibernate.Linq against it until now.  So if you are still looking to run the old version of NHibernate.Linq with NHibernate 2.0.1GA here are the files.

NHibernate.Linq for 2.0.1GA

I wasn’t sure that anyone was aware of this little project until I got a linkback from Ayende’s blog.

Of course I’m still waiting anxiously for the real Linq version that is being developed in the main trunk to mature as it looks like a far better stabler implementation.

6 Responses to “Linq update”

  1. Steinar Dragsnes Says:

    Hi again!

    Just being able to replace .Net Remoting transparently with Generic Remoting would be a great dead. If it is so hard to get this working, then I do not understand why you bother to strive for remote-auto-initialization of proxies. I think it is actually good that a LazyInitializationException is thrown. Especially when you are working remotely on the client side of the wire. This make you think about your configured default fetch plan, the expensiveness of having to go back to the server to get more data etc. This could easily become too transparent in auto-initialize mode and developers not very familiar with the architecture might end up creating code that do not preform well.

    I would go the traditional way and simply have a service and a OSIV boundary that reattach the stale entites as they are transmitted from the client.

    Auto-initialization can still be achieved by using AOP with the service on your client side controller objects. I outlined such an approach here:

    I do not think this is any great solution, it’s just a simple solution for automating client-side lazy-initialization and it took like a workday to write the code.

    Hope you solve those problems soon,

  2. Daniel Guenter Says:

    Thanks for your comments. Lazy loading entities is not the primary focus of this project although it seems to be something that people are interested in. I guess the way that I see it would be that lazy loading has performance implications no matter what setting you use it in. Even if you are directly connected to the database you must plan your fetch patterns or you will incur N+1 query penalties. On a remote client this is just more apparent as there is also the network to deal with. However lazy loading can definitely help with performance in a lot of situations as well, that’s why most modern ORMs include it as a feature.

    The AOP approach does work and in your case it probably fits your situation. I am just hoping for a more seamless way to use an NHibernate ISession agnostic of whether or not I am directly tethered to the database. Maybe this is just a pipe dream but time will tell I guess.

  3. David Nadaraia Says:

    When I try to run simple select query on this version with NHibernate 2.0.1 it throws NotImplementedException “The method Cast is not implemented”. Any ides how to resolve this?


  4. Daniel Guenter Says:

    Try running a ToList() before you run your cast. This will force NHibernate to pull the entities and you shouldn’t run into that error.

  5. Graham Says:

    Many people seem to be having trouble getting the latest NH Contrib trunk working with 2.0.1GA so thanks for this.

    However, I’ve come across a bug with this version with using it with proxy interfaces (e.g. session.Linq() etc.)

    There is a small patch (about 10 lines) available that I’m happy to apply to my version of the source code… but I can’t find (or don’t realise if I have) the source code that exactly matches the dll you posted.

    Can you post a link to the source that matched this dll?


  6. Daniel Guenter Says:

    Unfortunately the NHibernate.Contrib linq source has undergone considerable revision and is now being built against NH 2.1 beta dlls. I’m in the same situation as you now waiting for NH 2.1 while trying to get by on the old version of linq.

Leave a Reply