In my mapping-by-code posts series I've just completed, I reviewed the capabilities of both mapping-by-code and Fluent NHibernate in comparison to plain old XML mappings. There are some more or less serious bugs on both sides, as well as both solutions don't offer everything XML does. In each case, when I found the issue worth mentioning, I was looking if it was already reported and reported it myself if not. Here is the quick summary:
Mapping-by-Code
- Mapping-by-Code does not allow Unique in Component mapping - already resolved, will be fixed in NH 3.3
- PropertyRef and NotFound missing in ManyToOne mapping - already resolved, will be fixed in NH 3.3
- Setting the SqlCheck for custom SQL commands is not supported - patch provided, not yet pulled
- Where clause with many-to-many relation is missing - solution provided, not yet implemented
- Optimistic-lock option at entity level is missing
- Expression-based PropertyRef missing in OneToOne mapping
- ForeignKey in OneToOne missing - already resolved, will be fixed in NH 3.3
- UnsavedValue in Id missing - already resolved, will be fixed in NH 3.3
- DDL options in Id mapping missing
- ComponentAsId is broken - already resolved, will be fixed in NH 3.3
- UnsavedValue in ComponentAsId missing
Fluent NHibernate
- SqlInsert, SqlUpdate, SqlDelete, SqlDeleteAll should not be available in Component and DynamicComponent mappings
- Component's ParentReference Access type can't be defined
- Missing Key options for SubclassMap<T> and Join mapping (on-delete, foreign-key, unique, etc.)
- ManyToAny relationship not supported
- HasMany/HasManyToMany options missing (catalog, unique, loader, sql-XYZ)
- Cascade options missing
- OptimisticLock in HasMany/HasManyToMany broken (XML validation error)
- Nice to have: HasMany/HasManyToMany PropertyRef with expression parameter
- Table method in Join mapping is not chainable
- Lack of support for components as index in the dictionary
As you can see, the number of issues I've encountered is very similiar for both mapping-by-code and Fluent NHibernate. For mapping-by-code, majority of them were already reported and actions were taken. Actually, 5 of them are already resolved and wait for NH 3.3 release. I've reported 3 new issues (one of which was fixed in few days) and extended another one.
For Fluent NHibernate, I've reported 8 issues out of 10 encountered. Sadly, by now, none of them were even commented. It looks like there's no active development on FNH. I tend to agree that leaving issues in no man's land with no status at all is a sign of a neglected community. I'd prefer to have these issues closed with "won't do" status than ignored, for sure.
Sadly, you are correct that FNH development is currently languishing. In the FNH Google Group topic
ReplyDeletehttp://groups.google.com/group/fluent-nhibernate/browse_thread/thread/aa16eb4211417611?hl=en#
I commented:
"The big problem in FNH land these days is that nobody is actively maintaining it. James Gregory has had to step back for personal reasons, and no one else is filling the vacuum."
Some of us are trying to rectify this situation - maybe we can get things moving again.
Also, see the first posting, which describes a fairly unhappy experience with NH MbC.
-Tom Bushell
Well, that's of course true that FNH is more mature and far better documented. And unhappy experiences with MBC don't surprise me. Mine was not better at the very beginning, maybe I was just more patient :)
DeleteBut for me, MBC, with its cleaner API design, better maintenance and tight coupling to NHibernate is the future for mapping.
Anyway, keep up the good work on FNH, it's always better to have a choice :)