I have different kinds of products. Now, the AppProduct has different kinds of quantities - multiply of value, list of values, etc...
public class Product : Entity
{
}
public class Quantity: Entity
{
}
public class ListQuantity : Quantity
{
public virtual IList<int> Quantities { get; set; }
}
public class MultiplierQuantity : Quantity
{
public virtual int Multiplier { get; set; }
}
public class AppProduct : Product
{
public virtual Quantity Quantity { get; set; }
}
The question is: is it possible to map with FNH or NH at all? Particularly, with auto mapping. To me it would be natural to map products in their own tables, but quantities would be part of AppProducts table... that is, discriminated.
I tried different Subclass, JoinedSubclass, etc. ways without luck, each with different NH exceptions. It works only when both hierarchies are mapped by default with joined subclass. However, automapper can't map IList[int] automatically. If I set IList[Product] (to test) everything works perfectly. If I try to keep IList[int] using this mapping:
public class ListQuantityMap : IAutoMappingOverride<ListQuantity>
{
public void Override(AutoMap<ListQuantity> mapping)
{
mapping.HasMany(x => x.Quantities).AsElement("QuantitiesId");
}
}
if fails with System.Xml.Schema.XmlSchemaValidationException: The element 'class' in namespace 'urn:nhibernate-mapping-2.2' has invalid child element 'bag' in namespace 'urn:nhibernate-mapping-2.2'. List of possible elements expected: 'meta, subselect, cache, synchronize, comment, tuplizer, id, composite-id' in namespace 'urn:nhibernate-mapping-2.2'.
though the only difference in exported Orders.Core.Quantity.hbm.xml is one-to-many class type... i.e. NHibernate does not complain about bag in almost the same mapping.
(note: this is probably a bug that is fixed in recent FNH, issue #299).
Anyway, joined subclass is not the perfect solution here. I even think about doing just component in AppProduct and creating appropriate quantity object myself when property "QuantityType" is assigned... too weird, though. Or maybe switching to Linq2Sql will help? ;-)