[hibernate-dev] 6.0 - Type redesign

[Steve Ebersole]

One goal of the redesign is to build more friendly, easy-to-follow contract
for access to this metadata at runtime (legacy persister state).  Rather
than accessing pieces of information pertaining to attributes across many,
many arrays I wanted an array of a composite representation of these
attributes.  JPA defines it this way, so on some level you'd think it would
be pretty straightforward to move this direction.  The major pain-point I
have been facing is that JPA does not define "mapping information" at all
in its Metamodel/Types.  The main place this comes to a head is
EmbeddableType, especially given access to it directly on Metamodel *by
class*.  In JPA terms that return has to model the Embeddable (no mapping
info) rather than the Embedded.  And then further when we
expose EmbeddableType's attributes we have the same problem continued
because the context/root is the embeddable rather than the embedded.
Hopefully this makes sense, but as an example consider (using a "component
safe NamingStrategy):

@Entity
class Store {
    ...
    @Embedded
    Address headquartersAddress;
    @Embedded
    Address locationAddress;
}

@Embeddable
class Address {
    String streetAddress;
    @Embedded
    PostalCode postalCode;
    ...
}

@Embeddable
class PostalCode {
    String zip;
    String plus4;
    @ManyToOne
    City city;
}

Then consider that JPA frames access to this information as:

EmbeddableType<Address> addrType = metamodel.embeddable( Address.class );

Because it is generic to the Address embeddable, we have no access to the
specific embedded mapping info.  And if we follow this access down further,
it also means the same for accessing the attributes of that
EmbeddableType<Address>.
For example, accessing the "postalCode.zip" from the EmbeddableType<Address>
we'd have no ability to resolve whether that maps to
"headquartersAddress_postalCode_zip"
or "locationAddress_postalCode_zip".  And of course, as an ORM we need
access to that mapping information :)

Essentially that is the crux of the difficulty I have at the moment.

I know we could get around this by splitting (or keeping split) the notions
of ORM Type and JPA Type, but I would like to avoid that : this unification
is going to be important to the SQM Criteria support.

So the question becomes how to best handle exposing an "Attribute" with
mapping information as well as an "Attribute" without mapping information.

I will be working on some proposals for ways to do this over the next week
or so.  And maybe y'all see a solution easier than I do (I fear I may not
be seeing the forest through the trees atm).


On Thu, Jul 21, 2016 at 7:49 AM Steve Ebersole <steve at hibernate.org> wrote:

> I am working on a larger response to some current challenges, but here is
> a quick response to your specific points...
>
> On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
>>
>> BasicType does not handle multiple column and compositeType is the
>> mebedded case. How would multi-column types would be handled?
>>
>
> In terms of what exactly?  Assuming you mean access to the JDBC
> descriptors, that is still being determined.  At the moment there is no
> single Type-level access to this information.  Each specific Type
> sub-interface defines access differently.  I am not a fan of that that
> aspect.  The other approach is to define a plural form on Type
> (Type#getColumnMappings), and BasicType would just ensure that there is
> just one.
>
>
> Why do you need to ”unscope" the TypeConfiguration? What do you gain from
>> it? I’m trying to picture a reuse use case?
>>
>
> Functionally we do not gain anything.  I was just trying to be balanced.
> We injected the SF into the TypeConfiguration, I wanted to un-inject it as
> well for 2 reasons:
>
>    1. release the reference to the SF
>    2. prepare the TypeConfiguration for binding to another SF.
>
> The only use case I had in mind was tests where we occasionally build
> multiple SF instances from a single Metadata.
>
>
> Methods of Type needing Session: I used to call them passing null in some
>> old code and hoping for the best. Are the reasons for using Session still
>> present? Would be nice to get rid of that.
>>
>
> This is only ever needed (sometimes) from EntityType.  I guess it depends
> which specific method(s) you are asking about.  For some (reading, writing)
> yes I think we will continue to need the Session: it is used for access to
> JDBC as well as other needed interactions with the Session/PC (scheduling
> ids for batch load, etc).  For other methods, maybe not.
>
>
> On the genericization of Type, it would be extremely nice indeed for OGM,
>> but it would require to genericize SqlTypeDescriptor and its methods
>> essentially. Not necessarily super trivial.
>>
>
> I understand that.  It is not a primary goal for me tbh.  But if we can
> get a decent design for the ORM case and can see an easy way to extend this
> to OGM without negatively impacting ORM I am all for it.  Given the
> delegation to Binder and Extractor I think this will be doable, although I
> assume we will need some parameterized param object to make this work.  The
> paam object would give us access to "JDBC services" in ORM and something
> else in OGM.
>
>
>