Actually I was thinking more about JPA type and how it fits into this
design and I came to the interesting conclusion that JPA's Type contract is
really more akin to our JavaTypeDescriptor, supposing we add support for
classification (entity, basic, etc) and attributes.
We discussed on HipChat some last week, and Chris and Andrea agreed in
principle. I am going to play around with this approach some this week.
On Fri, Jul 22, 2016 at 2:22 PM Steve Ebersole <st...@hibernate.org> wrote:
> On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard <emman...@hibernate.org>
> wrote:
>
> An alternative that I can think of is as follows. I'm assuming that the
>> data that needs to be contextualized by the path is mapping in nature or
>> at least not at all represented in the JPA types.
>> Each (JPA) type instance would be inherently specific to the path it
>> comes from. It would keep exposing the JPA non contextualized info but
>> also add contextualized info.
>>
>> HibernateEntityType<Foo> fooModel =
>> (HibernateEntityType<Foo>)
>> entityManagerFactory.getMetamodel().entity(Foo.class); // considered a root
>> for navigation
>>
>> for (HibernateSingularAttribute sa : fooModel.getSingularAttributes()) {
>> if (sa.getPersistentAttributeType() == EMBEDDED) {
>> HibernateEmbeddableType et = (HibernateEmbeddableType)
>> sa.getType();
>> for (HibernateSingularAttribute esa :
>> fooModel.getSingularAttributes()) {
>> if (esa.getPersistentAttributeType() == BASIC) {
>> int span = esa.getPhysicalInfo().getColumnSpan();
>> }
>> }
>> }
>> }
>>
>>
> Yes this is quite similar to what I had in mind. One thing I had
> envisioned differently was to have sa.getPersistentAttributeType() ==
> EMBEDDED translate as the attribute being an EmbeddedAttributeMapping which
> gives access to what I think you mean by "physical info".
>
> But other than that, yes I think we see it the same way.
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
