jandex binding work
A page to collect proposals, todos and follow-up work in regards to the ongoing (long-term) jandex-binding work.
https://hibernate.atlassian.net/browse/HHH-8893
Essentially:
- Provide an "extended"
orm.xmlschema which adds Hibernate-specific definitions "on top of" the JPA orm.xml schema - Deprecate
hbm.xmlsource and temporarily provide transformation (both on-the-fly and build-time) ofhbm.xmlto this new schema
Some open questions...
Definable defaults include at this level:
- package
- catalog
- schema
- attribute accessor
- cascades
- laziness
The problem is that there is no corollary in annotations. <persistence-unit-defaults/> does not have the same semantic (its per-SF/EMF, as opposed to per-mapping).
For reference, the definable defaults in <persistence-unit-defaults/> include:
- (jpa) AccessType (as opposed to Hibernate's caching AccessType)
- (jpa) catalog
- (jpa) schema
- (jpa) entity-listeners
- (jpa) cascade-persist
- (jpa) delimited-identifiers
- (hbm) default-access (attribute accessor - choice, with AccessType)
- (hbm) default-cascade (Hibernate's cascade types - choice, with cascade-persist)
- (hbm) auto-import
- (hbm) default-lazy
To be honest, in retrospect I'd lean towards removing the Hibernate-specific elements from <persistence-unit-defaults/>. I'd still like to explore an extended form of persistence.xml, which imo is a much better place for this stuff.
One option is to make these "mapping local" defaults into annotations - i.e., @LocalDefaults with schema, catalog, etc (package would make no sense).
@LocalDefaults(
catalog="THAT_DB",
schema="YABBA_YABBA_DO",
...
)
@Entity
public class ...
I like this option. The easiest is to limit this annotation to TYPE target. PACKAGE target would be great too (allowing a hierarchical resolution) but would require more work.
Another option would be to somehow build the "entity binding context" relative to the xml.
package name defaults specifically - see comments in org.hibernate.boot.model.source.internal.hbm.HbmXmlTransformer#getFullyQualifiedClassName. Basically comes down to whether the extended orm.xml schema should support the idea of setting package names per mapping document. This affects how we transform hbm.xml.
An implicit focus of the larger context of this work is to better separate things into bootstrap phases. This is sort of an amorphic requirement, but I wanted to list out the specific considerations..
specifically accessing the "application classloader" to load classes we may want to enhance. Historically this is a chicken-egg concern (generally you'd load the Class to look at its metadata). Note that this is not the purpose of HCANN, nor does HCANN do this at all; HCANN is solely about merging XML and annotation metadata.
JPA specifically defines a "temp ClassLoader" for this purpose (although says it should be limited to loading resources). Additionally, Jandex itself gives us an an advantage there because it reads the .class file directly rather than asking the VM for the Class.
Specifically it is for any "managed class" (entity, embeddable, mapped-superclass) that we need to delay loading - not to mention there may not even be a Class (EntityMode#MAP).
This is mainly a WildFly issue I think as they allow DataSource to be dynamically defined by the deployment which apparently happens after they start the ORM? Surely I am explaining this wrong, right? ;)
Anyway, we do need to be able to handle this case where the DataSource is not available upon bootstrap.
Relatedly, we also need to account for the database not being available....
Even if the DataSource is available, the database itself may not be. How should we handle cases where we are unable to access the database upon bootstrap?
I think we are pretty well covered after bootstrap. During bootstrap there are a few different options. http://in.relation.to/2017/02/16/hibernate-connections-cloud/ covers them specifically in regards to usages in cloud.
The trickiness is that you need a "central point" (or at least a few limited points) where the logic of whether the "connection provider" is ready yet or not. Luckily, for us I think that either ConnectionProvider or LogicalConnection could fill this role.
Question: What should happen when we do not have access to the database during bootstrap in regards to schema-export? Should it be tried later when we first have access?
Similar concerns to DataSource, but I think we have a well defined set of ways to deal with it for CDI already. Added here for completeness