* Split BasicType "resolution" into 2 - one used for reading (mapping model) versus one used from writing (legacy persister model)
* @SqlTypeCode, @SqlType, @SqlTypeRegistration
* @JavaType, @JavaTypeRegistration
* @Mutability
* jdbc_mappings.adoc section for DomainModel chapter
[*] At the moment, neither @SqlTypeRegistration nor @JavaTypeRegistration support has been implemented
[*] Still need to make sure @Mutability is propogated properly in all the cases
[*] jdbc_mappings.adoc still needs a lot of attention
For reference, this is the script being applied:
find . -type f -name '*\..java' -o -name '*.\.adoc' -o -name '*.\.gradle' | xargs sed -i 's/javax\.validation/jakarta\.validation/g'
Applying the following script, and setting the current value as a
documentation parameter:
find . -type f -name '*.java' -o -name '*.adoc' -o -name '.xml' | xargs sed -i 's/https:\/\/javaee\.github\.io\/javaee-spec\/javadocs\/javax\/persistence\//\{jpaJavadocUrlPrefix\}/g'
Having the script might help re-migrating existing documentation patches,
or forward porting subsequent improvements from previous branches.
The javadocs for JPA 3.0 have not been published yet at this point;
having a parameter will make it easier to leave this single task for
a later point in time.
- add TimestampWithTimeZoneDescriptor and use it in OffsetDateTimeJD
and ZonedDateTimeJD
- add ZoneOffsetJavaDescriptor for ZoneOffset attributes
- clean up string rendering for temporal types using ISO formats;
note that they do not need to implement objectToSQLString()
since they cannot be discriminators
Note that at this time very few databases have meaningful support
for the ANSI-standard TIMESTAMP WITH TIME ZONE type. This limits
the usefulness of TimestampWithTimeZoneDescriptor for now.
Also add in some missing but needed type mappings for temporal types
In the past the MOD columns were constructed based on the property name,
therefore if users specified a @Column/@JoinColumn like annotation and
changed the underlying schema column, the MOD column would continue to
be derived based on the property name.
This enhancement introduces a new ModifiedColumnNamingStrategy SPI that
comes with two implementations, a default/legacy mode that maintains
the prior naming model and an improved mode that will derive the MOD
name based on the naming strategy ORM used to derive the column name.
- work on `org.hibernate.query` (especially `NamedQueryRepository` and friends)
- work on `org.hibernate.sql.exec`
- work on `org.hibernate.sql.results`
- work on `org.hibernate.sql.exec`
- work on `org.hibernate.sql.results`
- work related to `org.hibernate.metamodel.model.mapping.spi.ValueMapping` - including "sketching in" the hooks with `org.hibernate.persister.walking`
In order to maintain backward compatibility with long-standing behavior,
this introduces a new configuration option which can be toggled to have
AuditReader#find implementations adhere to returning an exact match on
revision-number rather than one which is less-than or equal-to the
provided argument.
So a new configuration option org.hibernate.envers.find_by_revision_exact_match
provides users with the ability to be able to force this new behavior
while allowing legacy behavior to remain the default.