Actually I just realized I was a little smarter than this back then :D
`IdGeneratorStrategyInterpreter#determineGeneratorName` is actually passed
the GenerationType and a "parameter object". I can add access to the
generator name to the parameter object.
On Sat, Nov 25, 2017 at 10:18 AM Steve Ebersole <steve(a)hibernate.org> wrote:
The background is all in the Jira, but the crux is this... it is
better to
allow a user to do this:
@GeneratedValue( strategy=SEQUENCE, generator="my_seq")
rather than:
@GeneratedValue( strategy=SEQUENCE, generator="my_seq")
@SequenceGenerator( name="my_seq", sequenceName="my_seq" )
You can see that `SequenceGenerator` is completely unnecessary in this
case because it adds no new information beyond what is already available on
the `@GeneratedValue`.
This works great for `GeneratedValue#strategy=SEQUENCE` and
`GeneratedValue#strategy=TABLE`, however consider this mapping:
@GeneratedValue( strategy=AUTO, generator="increment" )
@GenericGenerator( name = "increment", strategy = "increment" )
Here we have the same underlying concern - the `@GenericGenerator` is just
noise, it adds no additional information. In keeping with the work done as
part of HHH-12125 it would be great to allow users to instead just say:
@GeneratedValue( strategy=AUTO, generator="increment" )
The problem here is that this last one is actually the responsibility of
`org.hibernate.boot.model.IdGeneratorStrategyInterpreter#determineGeneratorName`
to interpret, but it is not passed the `GeneratedValue#generator` value.
So the easiest solution would be to add an additional parameter to
`IdGeneratorStrategyInterpreter#determineGeneratorName` for passing in the
generator name. The concern here is that `IdGeneratorStrategyInterpreter`
is defined in the API space and could very well have custom impls.
A lesser solution wold be to add checks to the code that calls
`IdGeneratorStrategyInterpreter#determineGeneratorName` to check for
"magic" generator names before asking the
`IdGeneratorStrategyInterpreter`. This is just a very inflexible and
non-extensible solution, but maybe this works for 5.3 and we can adjust
`IdGeneratorStrategyInterpreter` as part of 6.0.
Thoughts?