Put another way, I think the problem (and probably the solution) here is
similar to JPA's Bindable (and Path) concept.
On Thu, Jul 21, 2016 at 2:27 PM Steve Ebersole <st...@hibernate.org> wrote:
> 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 <st...@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 <emman...@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.
>>
>>
>>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
