access to MappingMetamodel / RuntimeMetamodels #5563
Replies: 2 comments · 2 replies
-
|
TLDR; While I do agree that this is an important task, I do not think this is critical for 6.2 specifically.
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.
Ok Trump, we can avoid incendiary language like "evil" while discussing software development I think. Anyway, yes the original intention was to have 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 A good first step I'll undertake is to simply clean up |
Beta Was this translation helpful? Give feedback.
-
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.
It was just wordplay. To be clear I don't think there's anything wrong with its existence or with the
That would help, for sure.
Yeah, I guess that's what I'm looking for. |
Beta Was this translation helpful? Give feedback.
-
|
Also a minor point... There were a few issues with 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 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
So, in older versions of Hibernate, you used to be able to go to the
SessionFactoryto get hold of aClassMetadataorCollectionMetadatainstance 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:Metamodelstuff 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
MappingMetamodelobject or something similar. But there's currently no way to do that AFAICT, not without casting down toSessionFactoryImplementor.Plus, the layering is not even that clear to me. I think that
MappingMetamodelis supposed to be an API interface (not SPI), since it has an evil twinMappingMetamodelImplementor. But OTOH it exposes types that we always used to consider SPIs, likeEntityPersister,CollectionPersister, andTypeConfiguration. So it kind of looks like exposing it would break layering.ClassMetadata/CollectionMetadatabut with better names. It's not too late to change the API ofMappingMetamodel, since it's clearly marked@Incubating, and is anyway not exposed by theSessionFactory.@sebersole this is something for you to think carefully about.
Beta Was this translation helpful? Give feedback.
All reactions