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

[Steve Ebersole]

WDYM by "Hibernate-native Batching API"?


On Mon, Dec 7, 2015 at 12:57 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
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 at hibernate.org>
> 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 at gmail.com>
> > 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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>