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> 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