access to MappingMetamodel / RuntimeMetamodels

[gavinking]

So, in older versions of Hibernate, you used to be able to go to the SessionFactory to get hold of a ClassMetadata or CollectionMetadata instance that gave access to some of the services of a persister, without exposing "too many" internal details. There were a couple of imperfect things about these interfaces:

1. they had terrible names, and
2. they didn't really fit in with the JPA Metamodel stuff we introduced in JPA 2.0.

So, finally, in 6.0, @sebersole took them away, after a long period of deprecation. Which is fine. But, it's not clear what really replaces them.

What I would need here would be to be able to get a reference to the MappingMetamodel object or something similar. But there's currently no way to do that AFAICT, not without casting down to SessionFactoryImplementor.

Plus, the layering is not even that clear to me. I think that MappingMetamodel is supposed to be an API interface (not SPI), since it has an evil twin MappingMetamodelImplementor. But OTOH it exposes types that we always used to consider SPIs, like EntityPersister, CollectionPersister, and TypeConfiguration. So it kind of looks like exposing it would break layering.

• So, are we promoting these types to API?
• Or should we be introducing some new abstractions more along the lines of the old ClassMetadata/CollectionMetadata but with better names. It's not too late to change the API of MappingMetamodel, since it's clearly marked @Incubating, and is anyway not exposed by the SessionFactory.

@sebersole this is something for you to think carefully about.

[sebersole]

TLDR; While I do agree that this is an important task, I do not think this is critical for 6.2 specifically.

But, it's not clear what really replaces them.

I do not know of anyone/anything using those contracts; and to be honest, implementation wise, they have only ever gotten in the way. So while I agree that we should expose some mapping model as an API, I do not think this is critical for the 6.2 time-frame that we are currently working toward.

Honestly I had designed the mapping-model to be end-user friendly already. I think it evolved between inception and actual 6.x releases to where some aspects are probably not a good idea to expose. So to me, this really comes down to creating some level of minimized access to what is already there. I'd really prefer to not create a separate layer of meta-model we can expose to the user.

All that said, sure let's start the discussion about what this might look like.

Plus, the layering is not even that clear to me. I think that MappingMetamodel is supposed to be an API interface (not SPI), since it has an evil twin MappingMetamodelImplementor. But OTOH it exposes types that we always used to consider SPIs, like EntityPersister, CollectionPersister, and TypeConfiguration. So it kind of looks like exposing it would break layering.

Ok Trump, we can avoid incendiary language like "evil" while discussing software development I think.

Anyway, yes the original intention was to have MappingMetamodel be an API while MappingMetamodelImplementor was meant to be its SPI counterpart. Looking back over MappingMetamodel with world-view I do see that it has evolved in parts beyond original intentions exposing things that are CLEARLY internal details.

It really comes down to what we think is useful to expose to users. I'd not be against exposing everything, except that limits our ability to evolve and improve those contracts over time of course. I mentioned wanting to avoid creating a separate layer for this purpose - we should also avoid creating mini-views into the mapping model like we have had in the past with Queryable, SQLLoadable, etc as it is (1) confusing and (2) leads to many many many casts throughout the code base.

A good first step I'll undertake is to simply clean up MappingMetamodel moving internals into MappingMetamodelImplementor.

[gavinking]

I do not think this is critical for 6.2 specifically.

No, no, I'm not saying it is.

It would be better to do it later, so as to not do it in a rush.

Just wanted to make sure you had this in the back of your mind with the stuff you're already working on right now.

we can avoid incendiary language like "evil"

It was just wordplay. To be clear I don't think there's anything wrong with its existence or with the MappingMetamodel/MappingMetamodelImplementor split. I was just trying to clarify what was the role of each thing (i.e. who its clients are supposed to be).

A good first step I'll undertake is to simply clean up MappingMetamodel moving internals into MappingMetamodelImplementor.

That would help, for sure.

So to me, this really comes down to creating some level of minimized access to what is already there.

Yeah, I guess that's what I'm looking for.

[sebersole]

Also a minor point... There were a few issues with ClassMetadata and CollectionMetadata. To me the biggest was always the idea of "consistent" access whether it comes from the boot model or the runtime model.

Anyway, as I mentioned earlier, the intention was always to expose the mapping model as an API. During the development of 6.x we have gotten away from that intention because the contracts have "grown" to expose clearly internal details. But as already discussed, the entire mapping model is currently incubating which gives us some leeway.

For 6.2 what I plan is to expose MappingMetamodel as an unwrap target from SessionFactory. This allows users access. And given that this is all incubating, I think that is actually a great solution. See https://hibernate.atlassian.net/browse/HHH-15883