I recently stumbled again over the lack of being able to provide a prefix for an @Embeddable in the using class.
I know about @AttributeOverrides, but this is really cumbersome having to provide it manually each time.
Having the new naming strategies provides a little better support with the ImplicitNamingStrategy, prefixing all embeddables.
But prefixing all embeddables isn't what I'm looking for (sorry) :). What I would like to have is something like this, proposed in the JPA spec:

https://github.com/javaee/jpa-spec/issues/23

or already implemented by:

https://github.com/ebean-orm/javax-pers ... i/issues/2

Although from my point of view "prefix" would be perfect, the experts tend to provide a custom naming strategy hook like you guys already provide to handle this.
Are there any plans to implement that upfront :)?

The problem with the existing naming strategies you guys have, is that I can't implement my own to provide a case specific prefix.
I tried to implement my own naming strategy, but in there I didn't find a way to get e.g. annotation information to decide whether to add
a prefix or not (e.g. by a custom annotation). Also in the interesting methods there's no information about the current entity which is currently processed.
I even tried to get that kind of information from the Ejb3Column Impl (bad, but looks promising for that purpose) but since it's an anonymous class that is passed
as an argument to the strategy, I can't get hold of it.

So my question is, is there currently any way to get that "prefix" somehow working? Maybe I've overlooked something in the naming strategies?

That JPA issue is just a request proposal. It never made into the JPA specs. Hibernate does not provide support for this either.

Now, since the database is supposed to drive the schema changes, you already have the columns and justs need to map them to JPA entities, embeddable or basic types. So, realistically speaking, how many embedabbles will you have in a single entity?

Having more than one is more the exception than the rule. Since you can map all the columns manually, using @AttributeOverride, you already can handle this atypical use case. I don't think that adding a JPA feature just for this use case pays off.

To conclude, you need to assign the mapping manually, and it's unlikely that this will change anytime soon.