Breaking changes with NHibernate 4 update
I see what's new and fixed in NHibernate 4.0
I would like to know if anyone had a question about updating hbm mappings from NHibernate 3 to 4?
I'm afraid there is more emphasis on smooth rendering these days. I can check out the more obvious changes, but would like to know if there were any subtle issues that anyone faced in a production environment that might not be so obvious at first.
This looks like a major update, and you would expect the risk of regressions to exist.
source to share
FYI, I found a new bug that got thrown. We are using Mapping By Code and we had an entity that had multiple mappings Bag
with the type Fetch
set to Join
as of NHibernate v 3.3.x. This is no longer allowed in version 4.0.x.
We got a bug Cannot simultaneously fetch multiple bags.
that makes sense with what's needed behind the scenes, but should technically be considered a change. NHibernate was not good enough to tell us which mapping was causing the problem.
source to share
We ran into the same problem with a rather large QueryOver
- Cannot simultaneously fetch multiple bags
, with the mappings of Nhibernate 4 and FluentNhibernate.
The solution on our FluentMaps installed AsSet()
(according to our support fields) which eventually resolved the issue.
As requested in the comment, here is a small example of our mappings before and after the exception:
This is a very simplified showcase of our classes that called Cannot simultaneously fetch multiple bags
. The abstract Entity
class belongs to the S # Arp lite architecture . Before the changes, it looked something like this.
public class OrderHeader : Entity
{
public virtual IList<OrderItem> Items { get; set; }
}
public class OrderItem : Entity
{
public virtual decimal Price {get; set;}
public virtual string ItemNumber {get; set;}
public virtual OrderHeader Header {get; set;}
}
public class OrderHeaderMap : ClassMap<OrderHeader>
{
Id( e => e.Id).GeneratedBy.Native();
HasMany(e => e.OrderItems).Inverse();
}
public class OrderItemMap : ClassMap<OrderItem>
{
Id(e => e.Id).GeneratedBy.Native();
References(e => e.Header).Not.Nullable();
}
As you can see, the OrderHeader has IList
elements. Changing this parameter to
public class OrderHeader : Entity
{
public virtual ISet<OrderItem> Items { get; set; } // ISet here
}
public class OrderItem : Entity
{
public virtual decimal Price {get; set;}
public virtual string ItemNumber {get; set;}
public virtual OrderHeader Header {get; set;}
}
public class OrderHeaderMap : ClassMap<OrderHeader>
{
Id( e => e.Id).GeneratedBy.Native();
HasMany(e => e.OrderItems).Inverse();
}
public class OrderItemMap : ClassMap<OrderItem>
{
Id(e => e.Id).GeneratedBy.Native();
References(e => e.Header).Not.Nullable().AsSet(); // Explicit AsSet
}
So, ISet
and explicit AsSet()
on the display made the problem go away. This code snippet is very simplified and we had several objects in QueryOver
c HasMany()
IList
- when all were updated to ISet
, it worked correctly.
source to share
I wouldn't worry too much about hbm itself. FluentNHibernate "compiles" to XML, which is passed through the display layer. NHibernate's native code mapping also uses parts of the same code as hbm files.
Anyway, the display code hasn't changed much. Any regressions are likely to be in other parts.
source to share