Skip to content

Conversation

geoand
Copy link
Contributor

@geoand geoand commented Mar 29, 2019

Fixes: #1743

Note: I'm not sure if where I added the reflection is the "proper" place or it should be moved to the JpaJandexScavenger class for example.

Copy link
Member

@Sanne Sanne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Could you add a test?

Set<String> strategies = new HashSet<>();
for (AnnotationInstance annotation : index.getIndex().getAnnotations(GENERIC_GENERATOR)) {
String strategy = annotation.value("strategy").asString();
if (strategy.contains(".")) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wondering: why checking for the dot being contained in the strategy string?

Copy link
Contributor Author

@geoand geoand Mar 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I am not mistaken, strategy could be a simple string, but maybe I am mixing this with the strategy from GenericValue?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you're right it could be a special keyword, but also it could be a "fully qualified name" with no package. (That's far fetched but some people do it!)

We also need to deal with the opposite problem: custom identifier generators can be registered with any name, I'm not aware of a rule that prohibits these to have a "." in the name.

sorry I know that's all bad news but that's how it is :)

It might help to peek into org.hibernate.id.factory.internal.DefaultIdentifierGeneratorFactory#getIdentifierGeneratorClass.

you could also - instead of registering these for reflection - instantiate the various identifierGenerators , store them in an immutable map, and insert a custom IdentifierGeneratorFactory implementation in the ORM bootstrap registry.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a problem at all, I'll revisit later on tonight or over the weekend if you don't mind :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, thanks a lot!

Copy link
Contributor Author

@geoand geoand Mar 31, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WRT the second approach IIUC I would have to change this with an Initiator that would return the custom IdentifierGeneratorFactory, correct?
I'm asking because I haven't looked at the Hibernate part of Quarkus before ( this PR is a great opportunity to do so :) ) and I don't want to stray down a completely incorrect path :P.

// register the strategies of @GenericGenerator for reflection
Set<String> strategies = new HashSet<>();
for (AnnotationInstance annotation : index.getIndex().getAnnotations(GENERIC_GENERATOR)) {
String strategy = annotation.value("strategy").asString();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the asString() method could hit an NPE ?

Copy link
Contributor Author

@geoand geoand Mar 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought it couldn't because the strategy field is necessary for GenericGenerator, but I guess we can be defensive, it doesn't hurt :)

@Sanne Sanne added the area/persistence OBSOLETE, DO NOT USE label Mar 29, 2019
@geoand
Copy link
Contributor Author

geoand commented Mar 29, 2019

I will also go ahead and add a test for this

@geoand
Copy link
Contributor Author

geoand commented Mar 29, 2019

It looks like my test is not passing locally so I need to dig in more

@geoand
Copy link
Contributor Author

geoand commented Mar 29, 2019

Should be good to go now

@geoand
Copy link
Contributor Author

geoand commented Mar 31, 2019

@Sanne I added another commit that implements the strategy you propose - to the best of my understanding. There are probably a few things wrong since I am not really familiar with the Hibernate internals :).

Update
The native test seems to be failing, I clearly haven't understood how RecordableBootstrap and FastBootMetadataBuilder#registerIdentifierGenerators come into play here.

@Sanne
Copy link
Member

Sanne commented Apr 1, 2019

thanks @geoand , I'll have a look.

@geoand
Copy link
Contributor Author

geoand commented Apr 1, 2019

Looking forward to it :)

@Sanne
Copy link
Member

Sanne commented Apr 1, 2019

@geoand great work on figuring out how the ORM boostrap works 👍 And I'm sorry I didn't put more comments, there's a lot to do still :)

I found a couple little problems:

  1. since you're re-implementing the mapping name -> class, this approach isn't allowing to use any of the embedded IdGenerators liste in org.hibernate.id.factory.internal.DefaultIdentifierGeneratorFactory#generatorStrategyToClassNameMap
  2. as far as I can see, not dealing with generators implementing Configurable, might break some implementations
  3. it's not applied as the "captured state" in this case needs to be folded into the Metadata instance; sorry I mentioned the service registry, but it seems like these are already initiatiated by the time the second service registry is created. Apparently listing it in PreconfiguredServiceRegistryBuilder is unnecessary.

I'll clean this up, I have a local branch already..

@geoand
Copy link
Contributor Author

geoand commented Apr 1, 2019

Thanks for the explanation @Sanne, it is highly appreciated! I am looking forward to seeing how it all comes together since it's a great opportunity to learn about Hibernate internals 😉

@Sanne
Copy link
Member

Sanne commented Apr 1, 2019

closing this one, replaced by #1809

@Sanne Sanne closed this Apr 1, 2019
@Sanne Sanne removed coding-in-progress area/persistence OBSOLETE, DO NOT USE labels Apr 1, 2019
@geoand geoand deleted the #1743 branch April 2, 2019 07:51
@gsmet gsmet added the triage/duplicate This issue or pull request already exists label Apr 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

triage/duplicate This issue or pull request already exists

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants