Hi, I made a pull request with this change.
Also ran all the test and all of them ran ok (had to change a few exeptions in some checks). The pull request is https://github.com/nhibernate/nhibernate-core/pull/437 The jira case is https://nhibernate.jira.com/browse/NH-3771 Anyone else is interested in this feature in order to move it forward ? Best Regards Carlos El lunes, 30 de marzo de 2015, 14:34:32 (UTC-3), tikuna escribió: > > Hi, > > We are using NHibernate, and got some processing that modify a big chunk > of data; and are using Version control for Optimistic Locking. > > In the process, inserts are done using batch processing with very good > performance, but updates are doing a data base roundtrip each (if I take > out optimistic locking with version from the entity, updates are executed > in batch's). > > I find in the documentation this: > > > - > > optimistic concurrency checking may be impaired since ADO.NET 2.0 does > not return the number of rows affected by each statement in the batch, > only > the total number of rows affected by the batch. > > Browsing the source files, found that in AbstractEntityPersister define > the IsBatchable property looking at the optimistic lock strategy. > > Since all the updates done in batching, have the ID (and the VERSION), is > not enough to have the total number of rows affected by the batch in order > to know if all the updates were sucessfully done? Is it really necessary to > have the rows affected by each statement of the batch? > > Any improvement to make possible to do the updates in batchs will really > boost performance. > > Thank you very much ! > > Tikuna > > > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/d/optout.
