Hello Sergey. We have checked that: the mapping files are embedded and correctly read into the session.
The thing is that it breaks in sourcecode: but only if we put the joined-subclass in a separate hibernatemappingfile AND use the abstractclass.
We are sure the mappingfiles are correctly loaded, because if we change the sourcecode to use the concreteclass, records are read in from the database. Note: we really think we found a bug in NHibernate.
While basicly it should not matter how our code looks like, right?
example:
Code:
List<....> IRepository.GetItems(List<int> offerItemIds)
{
List<AbstractClass> itemList = new List<AbstractClass>();
ISession session = OurSession.CurrentSession;
ICriteria NHibernateCriteria = session.CreateCriteria(typeof(AbstractClass));
NHibernateCriteria.Add(Expression.In("GeneralItemId", generalItemIds.ToArray()));
try
{
IEnumerable<AbstractClass> enumerable = (AbstractClass[])ArrayList.Adapter(NHibernateCriteria.List()).ToArray(typeof(AbstractClass));
itemList = new List<AbstractClass>(enumerable);
}
catch(Exception exception)
{
... log exception..
}
......
dostuff
foreach(ConcreteClassA in itemList)
....
return itemList
}
Let me try to explain what we found out:
In code above, it is possible to change all references AbstractClass to ConcreteClassA.
If we have one mappingfile, we can use AbstractClass.
If we put the joined-subclass in a separate mappingfile, the code with AbstractClass breaks with the mentioned error (cannot instantiate abstractclass) while if we change the code to use the ConcreteClassA, it works in both ways (using one mapping file or putting the joined-subclass(es) in their own mappingfiles).
..
Also: we know the separate joined-subclass mapping files are read because otherwise we get the error about the 'extends' class not known: so all mappingfiles must be read in order.
Login
FAQ
Search
