NH-3675 - Support Bulk Inserts

[rjperes]

https://nhibernate.jira.com/browse/NH-3675
Initial implementation with unit tests

[hazzik]

I don't like this code!

[rjperes]

And why is that? Another option is to return null, that is, not have a default bulk provider

[hazzik]

Because it uses "is-as" checks. A preffereble way is to use "as" and compare to null. Mainly because "is" and "as" are compiled to the same IL opcode "isinst".

[rjperes]

Yes, but that is totally irrelevant. But I changed this method to always use stateless session, don't want to store these entities in the first level cache

[hazzik]

Hi @rjperes, thanks for the great work. But can you please utilize IEntityPersister.GetPropertyValuesToInsert to populate DataTable instead of DataBinder?

[rjperes]

Can't use IEntityPersister.GetPropertyValuesToInsert because it returns an array of objects, containing possibly complex classes, in the case of components, many-to-one or one-to-one associations.

[hazzik]

2014-10-29 21:15 GMT+13:00 Ricardo Peres [email protected]:

Can't use IEntityPersister.GetPropertyValuesToInsert because it returns an
array of objects, containing possibly complex classes, in the case of
components, many-to-one or one-to-one associations.

We eitther need (1)to teach IType to set values to a DataTable, instead of
IDbCommand; or (2) use IType.Disassembly and IType.Resolve

[hazzik]

Following if-then-else can be replaced with only one

var abstractEntityPersister = persister as AbstractEntityPersister;
if (abstractEntityPersister != null) {
    table.TableName = abstractEntityPersister .TableName;
}

Because SingleTableEntityPersister, JoinedSubclassEntityPersister, and UnionSubclassEntityPersister inherit AbstractEntityPersister and TableName is it's property

[hazzik]

Btw, persister is already AbstractEntityPersister, so just persister.TableName;

[micmerchant]

Hello, I stumbled over this pull request today and would appreciate if this feature would be accepted. We've also integrated a bulk implementation for MSSQL done in the same way in our product and I would consider to replace it by native NHibernate functionality in this case.

However, I got some issues:

• What about insert listeners? If there are some specific listeners targeting the entity type, shouldn't they be called in case? An additional argument could be added e.g. bool callListeners
• What about using ISession over IStatelessSession and adding an additional parameter e.g. bool attachToSession?
• What about logging? It would be useful to log at least the ids of the entities to be inserted, in order to track it via the NHibernateProfiler.
• I see the table configuration as a possible performance issue, because it's done with every insert call. What if a hash map having the entity type as key would be incrementally filled? Then you would be able to retrieve the table configuration using the dictionary. Of course you would have to call DataTable::Clear after every call.

[fredericDelaporte]

The PR opener having deleted his nhibernate repository, it seems likely to me this PR will not move forward unless someone re-issue it and work on it. For how to do that with a deleted repository, one way is to do like here.

[micmerchant]

What a pity.