Change integral version seed value to 1

[beikov]

The idea is to change the version seed value from 0 to 1. I also think that we should treat a primitive version value of 0 (i.e. the JVM default) like a null and inject the seed value in this case. This will help to make sure that primitive versions behave the same way as wrapper versions. See #5481 for some background.

Conclusion: Won't do

[gavinking]

I mean, I'm totally in favor of this, but it would make Hibernate incompatible with its own data. I mean, if you had an existing database with rows with version 0 in it.

[beikov]

If we change the seed value to 1, all that would change AFAICT is that new entities would now be saved with version 1 instead of 0, which is what Steve mentioned could be a problem if someone depends on 0 to mean something special. I guess that's reason enough not to change the seed value, unless you have different opinions on this?

[Sanne]

Ok but let's bear in mind you might be reading a 0 from the DB and that's not necessarily the "special value" - could be the current state.

Tangential, and just playing devil's advocate (I actually like the proposal), but need to also consider that some people actually have opinions on what value their sequences should be starting from. I think it's ok for us to enforce, but bear it in mind.

[beikov]

I think you might be misunderstanding how the seed value is used.

On startup, we determine the "unsaved value" based on a "template instance" of an entity. During persist, we compare the value of an entity against the "unsaved value", and if it determines it is "unsaved", we set the version to the seed value. Also see org.hibernate.engine.internal.Versioning#seedVersion.

So the only observable effect of such a change would really be just that we save 1 instead of 0 on persist.

[gavinking]

Well the issue arises if we suddenly start interpreting objects with version 0 as "unsaved". Which is the motivation for making this change.

[beikov]

I guess the way this is implemented right now, means that changing the seed value will alter the determination of "transient"/"unsaved" of an entity object on merge. The scenario that would change is when having an entity that uses 0 as default value for the version property:

@Entity
class A {
    @Version
    Integer version = 0;
}

but also

@Entity
class B {
    @Version
    int version;
}

In these cases, we right now determine VersionValue#UNDEFINED, but if we change the seed, we will determine VersionValue(0), which means that zero is treated as "unsaved"/"transient".

This is currently used in AbstractEntityPersister#isTransient. When merging an entity object with an assigned id and version 0 (assuming it is not loaded in the persistence context) it would now treat such an entity as transient rather than detached, which means the merge does an insert, whereas before it would have loaded the entity first and only then decide whether to flush anything.

I just wanted to document my findings here. I guess this is evidence enough that messing with the seed will probably cause issues.