What I am thinking at the moment is to change up
org.hibernate.metamodel.spi.binding.EntityIdentifier to look like:
public class EntityIdentifier {
private final EntityBinding entityBinding;
private EntityIdentifierNature nature;
private IdentifierAttributeBindings attributeBindings;
private IdClassBinding idClassBinding;
private Map<String,String> derivedIdMap;
private IdentifierGenerator generator;
}
1) IdentifierAttributeBindings would play sort of the same role
as org.hibernate.metamodel.spi.binding.EntityIdentifier.EntityIdentifierBinding.
Essentially it would hold the binding state for each of the identifier
attributes (those marked with @Id or @EmbeddedId). Still not sure the best
external representation of this. Exposing a simple
List<SingularAttributeBinding> for all identifier natures versus
specialized IdentifierAttributeBindings for each nature are running a
neck-and-neck race atm. Thoughts? Votes?
2) IdClassBinding would be a
specialized org.hibernate.metamodel.spi.binding.EmbeddableBindingContributor
for describing the @IdClass mapping
3) `derivedIdMap` holds the various @MapsId mappings for the entity. I was
tempted to move this off to IdClassBinding except that @MapsId also refers
to @EmbeddedId attributes.
Thoughts? Worries? Concerns?
On Mon, Apr 7, 2014 at 10:27 AM, Steve Ebersole <st...@hibernate.org> wrote:
> I've been spending a lot of time the last 2 weeks trying to get a good
> "mental model" as to how to best model the information pertaining to an
> entity's primary key. Most of this effort went into trying to understand
> JPA's "derived identity" support.
>
> First and foremost I want to get away from modelling this (in the
> metamodel) as a singular attribute. This is unnatural in the
> "non-aggregated composite id" case forcing us to build a "virtual"
> attribute. I think that this is very doable with the distinction I
> recently added to the metamodel between Embedded/Embeddable.
>
> Next is to finish up support for IdClass, which should be close to done.
> Gail, I know you had mentioned a case where that support was lacking.
> Could you send me the specifics so I make sure we get that case covered?
>
> Beyond that is mainly incorporating support for JPA "derived identities".
> With that, I want to share some of my understanding and see if I missed
> anything...
>
> "Derived identity" support is essentially Hibernate's much older "foreign"
> identifier generator, namely that the child entity gets (all of or part of)
> its identifier from a to-one association defined on it, from its "foreign
> key" value. But of course the spec verbosely covers all the ways this
> might happen.
>
> The very first thing I noticed is that the examples in the spec come in 2
> distinct top-level flavors. Examples 1-3 are cases where the "parent id"
> is simply part of the "derived (child) id". Examples 4-6 are cases where
> the parent id *is* the child id (shared pk). I am not sure how important
> this distinction is in practice, but I also noticed that @MapsId is only
> pertinent wrt the second set of cases where we have the shared pk. This
> was the first time I have noticed that distinction.
>
> The one monkey wrench that JPA throws into the works here is that there
> are essentially multiple views of an entity's PK. As one example, take the
> spec's "Example 4.a":
>
> @Entity
> public class Person {
> @Id String ssn;
> ...
> }
>
> @Entity
> public class MedicalHistory {
> @Id
> @OneToOne
> @JoinColumn(name="FK")
> Person patient;
> ...
> }
>
> Ultimately, the primary key of MedicalHistory is the `ssn` of its
> associated Person. Thus both of these are valid:
>
> entityManager.find( MedicalHistory.class, somePerson );
> entityManager.find( MedicalHistory.class, somePerson.ssn );
>
> For those who have seen it, this is the reason for the wonkiness inside
> Hibernate's runtime engine wrt incoming id type while doing a load.
>
>
> I am still going through all the use cases (ours plus JPA) to make sure we
> get everything covered. But I wanted to hopefully get some discussion
> started around this and get any thoughts y'all might have.
>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
