nHibernate 3 support

Topics: General
Aug 21, 2011 at 1:06 PM
Edited Aug 21, 2011 at 1:55 PM

I would like to know if there is some plan to use nHibernate 3 (rather than 2) in Orchard? nHibernate 3 contains some extensibility points which could be interesting, for example to enable easily spatial queries without heavy orchard modifications.

I looked at Orchard Data Layer, and tried to do the work myself, but there is one alteration that I wasn't able to port. However, good news: I don't consider myself as an nHibernate expert.
The alteration is the one adding "dummy" columns in the nHibernate model, in order to provide support for the dynamically loaded part records. The method used to achieve this is obsolete ("an internal implementation which shouldn't have been publicly exposed to quote the nHibernate team") and I am under the impression that this behavior can't be replicated with nHibernate3 without modifying it somewhat. Even if I don't think it would be complicated, I really don't like the idea.

Furthermore, is it planned to add extensibility points to the data layer? The session locator supports finding a session for a specific record type, but this feature is not enabled on the SessionFactory interface. I could add this feature myself by subclassing the default SessionFactory, SessionLocator and adding some SessionFactory selection logic. I furthermore could work on the MigrationInterpreter, but I didn't like the way I did this. A strategy pattern implementation would be a lot better than replacing the implementations involved.

For instance, I needed to add Azure Table support in an Orchard Module using a custom Azure Table nHibernate Driver. Ok, I have now a module which allows you to:

  • Create record classes inheriting from AzureTableRecord.
  • using migrations inheriting from IAzureTableMigration and writing things like AzureTableSchemaBuilder.CreateTable<MyAzureTableRecord>(); in the migration methods.
  • accessing the Azure Table storage with a simple IRepository<MyAzureTableRecord> injection.

However, like I said, I don't like the way I was forced to do this: Lot of code replication, Using SuppressOrchardDependency extensively... I have quite a lot of ideas to improve this, but if it isn't implemented in orchard core, it won't be easy to achieve something better than a what I feel is a hack (I had for instance -and not surprisely- to implement some recordBlueprint filtering logic at places it shouldn't belong to.... And I really don't want to replace the current CompositionStrategy implementation.)

Aug 21, 2011 at 1:49 PM
Edited Aug 21, 2011 at 1:49 PM

The Orchard team has been quite good at staying upto date with the latest 3rd party libaries and I would like to see this continue. As NHibernate 3.0 is a major milestone, im hoping the Orchard team could upgrade as a prereq for v2?

Aug 21, 2011 at 1:53 PM

Also logged a feature request for you http://orchard.codeplex.com/workitem/18092 - Go and Up vote it to increase priority

Aug 21, 2011 at 5:04 PM

The work has already been done, it's on the UpgradLibs branch right now. The only missing step is the medium trust compatibility, bu Andre told me a couple day ago that a recent NH commit should fix it.

Aug 21, 2011 at 5:13 PM

Two thumbs up!

Aug 21, 2011 at 7:10 PM

Thank you very much! I will look at it :)