HHH-19610 make GraphParser support subTypeSubGraph

[Asanio06]

Today, Jpa's NamedEntityGraph annotation supports the use of subclassSubgraphs to define graphs linked to the subtypes of an Entity. It is also possible, via the entityManager, to do the same thing via the addTreatedSubgraph function.

The goal of this ticket is to improve GraphParser so that it supports a syntax that does the same thing. In this way, Hibernate's own NamedEntityGraph annotation will have 100% of the same functionality as Jpa’s.

I suggest the following syntax for defining a subclassSubgraphs:

(GraphParsingTestSubEntity:sub), name, description

Here we have a sub-graph specific to the GraphParsingTestSubEntity type, which is a sub-type of GraphParsingTestEntity.

The ticket related to my proposal: https://hibernate.atlassian.net/browse/HHH-19610

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

https://hibernate.atlassian.net/browse/HHH-19610

[sebersole]

Hi @Asanio06, thanks for the PR!

Overall it's a good feature to add :)

I'm not a fan of using parenthesis here though - those are already used for sub-graphs so it introduces a bit of syntatic ambiguity. Sure, the use of the colon disambiguites it, but it also does so on its own:

GraphParsingTestSubEntity:sub, name, description

Bacause otherwise, something like this just looks odd -

(GraphParsingTestSubEntity:sub(subName, subOtherStuff)), name, description

whereas this is a little bit better:

GraphParsingTestSubEntity:sub(subName, subOtherStuff), name, description

[sebersole]

See also discussion at #hibernate-orm-dev > HHH-19610 Make GraphParser support subTypeSubGraph

[sebersole]

Some general comments -

1. I'd "reverse" the naming of the lexer and parser files - GraphLanguageLexer -> LegacyGraphLanguageLexer, etc. The thought process is that "Modern" will stick around.
2. I might have missed it, but I think another test/check that ought to be performed is the case of NamedEntityGraph#root being specified with LEGACY mode - this ought to result in an error.

[sebersole]

I was a bit torn whether we want to consider String rootEntityName() ... here to support dynamic models. The annotation can appear at the package level and apply to any entity...

But for posterity, I think this definition is fine.

[sebersole]

1. The thought process is that "Modern" will stick around.

I should have been more clear here. The lexer/parser you currently have named Modern* will stay around, at which point the "Modern" bit is wrong/pointless.

[Asanio06]

2. I might have missed it, but I think another test/check that ought to be performed is the case of NamedEntityGraph#root being specified with LEGACY mode - this ought to result in an error.

Hi @sebersole , on this point, I find it interesting to leave open the possibility of using NamedEntityGraph#root for Legacy mode.
Today, if a user in legacy mode includes a TypeIndicator, they will see the following logged:
Deprecated syntax when using @NamedEntityGraph: 'Type: attr1, attr2' is deprecated. Specify the root entity using the 'root' attribute instead of prefixing the graph with the entity type.
I can always change it if needed.

[Asanio06]

1. The thought process is that "Modern" will stick around.

I should have been more clear here. The lexer/parser you currently have named Modern* will stay around, at which point the "Modern" bit is wrong/pointless.

Done 🙂