Re: [hibernate-dev] Delay the identity generation to flush-time for transactional contexts too

WDYM by "Hibernate-native Batching API"? On Mon, Dec 7, 2015 at 12:57 PM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; wrote: > I'm sure it require a significant change since the persistence context is > very much tied to the entity identifier. > Theoretically, it could work because the identifier is required for > database operations and for merging as well. > > Because the EntityIdentityInsertAction already has the isDelayed property, > maybe we could better reason if we could eventually make this a reasonable > default. > Anyway, it's worth judging if it's worth the development cost and if we > can't afford the change, maybe we could add a Hibernate-native Batching > API > to offer an alternative. > > Vlad > > On Mon, Dec 7, 2015 at 8:04 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: > > > As soon as a new entity becomes "managed", it needs to be tracked by > > the Persistence Context (the container within each Session).. > > obviously, as otherwise we wouldn't be able to know what needs to be > > eventually flushed. > > > > And within the PC each entity must have an id assigned: it would be > > nice to have a data structure to be able to deal with reference > > equality, but then how would you know when a "merge" operation on a > > different object instance is meant to replace one of the previous > > references? > > > > I wonder if we could handle all corner cases like a merge operation by > > tracking references too (as an alternative to ids), and essentially > > have ids assigned as late as possible. > > > > But I'm pretty sure that we have an API contract that mandates that a > > user can read the Id after the entity has been "saved", even if we > > didn't commit yet, which implies the entities should also be > > instrumented so that a getId() can trigger a lazy initialization of > > the id. > > > > Since this lazy initialization needs to happen on the instances passed > > (and constructed) by the end user, I suspect such a feature would only > > be safe to be enabled for those using bytecode enhanced entities? > > > > Seems like a big one.. you think it's worth it? People might simply > > use an in-memory id generation strategy. > > > > interesting thoughts! > > > > Sanne > > > > > > On 6 December 2015 at 05:46, Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; > > wrote: > > > HI, > > > > > > I always wandered why the identity generator needs to assign an > > identifier > > > prior to flushing. > > > Because of this behavior, the JDBC batching is disabled which is bad > news > > > for MySQL where most setups use IDENTITY instead of TABLE generation > > type. > > > > > > Since the AbstractSaveEventListener supports the > > shouldDelayIdentityInserts > > > option for when there is no transaction n progress, we could make > this a > > > default anyway. > > > > > > If the inserts are delayed to flush-time, we could batch them based on > > the > > > current dialect. Only the SQL Server dialect and Oracle 11g don't > allow > > > fetching the resulting keys from a batch. But Oracle 12c (which > supports > > > IDENTITY), PostgreSQL and MySQL can save a batch of inserts and fetch > the > > > generated keys. > > > > > > If I judge from a Stack Overflow perspective, most questions are in > the > > > context of MySQL, so many Hibernate users use MySQL in fact. > > > > > > What do you think? Should we make this change and allow MySQL users to > > > batch JDBC inserts even for IDENTITY. > > > > > > Vlad > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >