I have a class structure like so:
public class Person
{
public virtual int Id { get; protected internal set; }
public virtual string Name { get; set; }
}
public class Customer : Person
{
public virtual string AccountNumber { get; set; }
}
Customer
is mapped as a subclass of Person
(using FluentNHibernate's SubclassMap<T>
), and the table structure is table-per-subclass (separate Person
and Customer
tables sharing an Id
column).
In my test, I open a stateless session and try to insert a series of Person
entities:
using (var stateless = sessionFactory.OpenStatelessSession())
using (var transaction = stateless.BeginTransaction())
{
var persons = new[]
{
new Person { Name = "Alice" },
new Person { Name = "Bob" },
new Customer { Name = "Cathy", AccountNumber = "001" },
new Customer { Name = "Dave", AccountNumber = "002" }
};
foreach (var person in persons)
stateless.Insert(person);
transaction.Commit();
}
If I run this with the ShowSql
switch on, I can see that there are no INSERT
statements generated on the Person
table (meaning that they are batched), but there are individual INSERT
statements being generated for the Customer
table (from which I infer that these are not being batched).
Oddly enough, I've found that if the derived type (i.e. Customer
) has its own collection (let's call them Orders
) and I Insert
each item in that collection directly into the same stateless session (not into the actual collection), it batches those too and has no trouble resolving the relationships. This behaviour seems to be entirely limited to derived classes of polymorphic entities.
Is this expected behaviour? If so, is there any way that I can rewrite the insertion code above to ensure that all of the subclass tables are batched as well?
(Note: I am using the SequenceHiLoGenerator
for all IDs, and I've configured the AdoNetBatchSize
accordingly, so this is not a general issue with batching, as far as I can tell. I can see the HiLo
table being hit when a batch operation would be occurring.)
After several days of digging and experimentation, the answer seems to be "yes". There are various scattered blog posts mentioning in passing that NHibernate has trouble batching subclasses - specifically when using the table per subclass strategy (which I've been using).
It's not an issue with the table-per-class-hierarchy strategy. Unfortunately, it was way too late in the game for me to be changing the persistence model (plus, I really dislike TPH from a relational DB design perspective), so I had to look at other options.
I was able to work around the issue in the following way for inserts:
SqlBulkCopy
to insert the derived classes into their own tables, using some scary voodoo based on casting the IClassMetadata
to AbstractEntityPersister
in order to get all of the column/table mappings;IStatelessSession.Insert
method as normal (repeat this process for collections with their own class hierarchies).Updates, I imagine, would be a lot more complicated, and probably very difficult to handle without relying on hard-coded table/column names; if I had to do this, I would probably rely on Stored Procedures (with Table-Valued Parameters, or staging tables) instead.
The resulting code is not pleasant to look at, but it makes for a significant performance improvement - at least 25% for normal-sized batches of about 20-30k.