Skip to content
This repository has been archived by the owner on Oct 4, 2018. It is now read-only.

jandex binding work

Steve Ebersole edited this page Oct 22, 2015 · 7 revisions

A page to collect proposals, todos and follow-up work in regards to the ongoing (long-term) jandex-binding work.

Unified mapping (XML) schema

https://hibernate.atlassian.net/browse/HHH-8893

Essentially:

  • Provide an "extended" orm.xml schema which adds Hibernate-specific definitions "on top of" the JPA orm.xml schema
  • Deprecate hbm.xml source and temporarily provide transformation (both on-the-fly and build-time) of hbm.xml to this new schema

Some open questions...

How to handle hbm.xml "mapping local" defaults?

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 effects how we transform hbm.xml.