<map name="Contracts" lazy="true">
<key column="employer_id"/>
<index-many-to-many column="employee_id" class="Employee"/>
<one-to-many column="contract_id" class="Contract"/>
</map>
<map name="Connections" lazy="true">I look at these and can't help but think that the concepts of "OneToManyPart" and "ManyToManyPart" are not the correct building blocks to be coming straight off the class map. A while ago I posted about the idea of the Fluent NHibernate API exposing methods such as HasBag, HasSet, HasMap rather than HasMany and now feel that the idea is worth revisiting. That said, I am not saying that we can't make it work well with HasMany and HasManyToMany, its just tricky at the moment because the underlying model isn't very rich. For example, OneToManyPart and ManyToManyPart do not share a base class so there is some significant duplication between the two (or lack of duplication, when I add something to OneToManyPart and -forget- to update ManyToManyPart accordingly, which is very often).
<key column="node1_id"/>
<index-many-to-many column="node2_id" class="Node"/>
<many-to-many column="connection_id" class="Connection"/>
</map>
class Employer
{
public IDictionary<Employee, Contract> Contracts { get; set; }
}
class Node
{
public IDictionary<Node, Connection> Connections { get; set; }
}
mappings:
employerMap.HasMap(x => x.Contracts)
.WithIndex( indexMapping => indexMapping.ManyToMany())
.WithEntities( entityMapping => entityMapping.OneToMany());
nodeMap.HasMap(x => x.Connections)
.WithKeyColumn("node1_id")
.WithIndex( indexMapping => indexMapping.ManyToMany("node2_id"))
.WithEntities( entityMapping => entityMapping.ManyToMany());
I spent about 6 hours this weekend going through and trying to convert ClassBinder.cs over to exclusively use Hbm* classes (i.e. HbmClass, HbmManyToMany, HbmProperty, etc) instead of passing “mystery meat” XmlNodes around.
I ended up having to give up because I got *WAY* too far down a rat hole. About 3 hours into it, I realized that this is not going to be an effective strategy since there is simply too much XML “magic” going on.
I can give specific examples if anyone cares, but rest assured, it’s not as simple as I had originally thought.
I’m starting to come to the mindset that the fastest way of accomplishing this task is to try to achieve as near 100% coverage of the XSD as possible and then gut the XML stuff. I know it sounds harsh, but it is simply TOO tied to XML for any other strategy to be effective.
One possible thought was to appeal to the community to send us as many models + HBM XML Maps + tests as possible to help us coverage as much ground as possible.
I’m still willing to do the effort, but I think that the work that needs to be done will not be accepted unless a good portion of the community is behind it.
Another possible option is to do the side-by-side mapping source that Fabio suggested, but this will essentially fracture the NHibernate mapping code and cause a schism. Eventually the code bases will have unique bugs and features and maintenance will become prohibitively convoluted.
It’s my sincere hope that everyone eventually chooses to go with this new mapping source and it becomes the de-facto standard, allowing the XML mapping to eventually die (or become a 2nd class mapping to the primary model-based mapping).
I’m loath to go down the schism road as I think it will be very painful and cause hard feelings among the community.
-c
Paul,
We could absolutely work against the Hbm* classes (or against a model on top of the Hbm* as Julian suggested) and then serialize to XML. I don’t think the perf hit from going to Hbm to XML is that bad. The real hit is the XML Schema validation in NHibernate, which we have to deal with either way.
The problem I was trying to solve is to get NHibernate off of its XML addiction and not have to incur the XML Schema validation tax, but this effort is a major effort and should be tabled for now (or the discussion should be moved to the NHibernate-devel list instead).
Back to Fluent NHibernate, If we’re going to get off of direct XML generation and switch to the Hbm* classes, then we should be aware of two things:
1.) It will make it slightly more difficult and brittle to deal with XSD changes on the NHibernate side
2.) It will be slightly more difficult to support multiple concurrent NHibernate versions
3.) If NHibernate ever does change to not use XML, we’ll have to have a major rewrite (again).
Perhaps we could map to a semantic model that can translate to Hbm? It sounds silly, but then we can use that model for other things (ORuM, backend entity data model, etc).
Thoughts?
Chad