Cannot use @NumericField on ID field when having inherited child entities

Description

It is OK to have @NumericField on the ID field of an indexed entity:

This is working perfectly, the ID field is added as a numeric field to the index.
But if I have an indexed entity that inherits its ID from a parent entity, it does not work anymore:

Hibernate Search now fails with this error:

There is no reason why this constellation should not be allowed, I think the only problem is that the numeric field validation does not take inherited ID fields of parent entities into account.

Environment

None

Activity

Show:
Yoann Rodière
January 11, 2017, 3:50 PM

Hey ,

I'm affraid it's still not enough, I adapted my test case and it still passes: https://github.com/yrodiere/hibernate-search/blob/HSEARCH-2536/orm/src/test/java/org/hibernate/search/test/engine/NumericFieldOnSuperclassIdTest.java
Did you manage to set up a failing test case?

Are those known issues also relevant when using Elasticsearch as backend, or only when using the old Lucene backend?

They are mostly relevant with the embedded Lucene backend, as far as I know.

What exactly does not work when trying to sort the document ID? Is this documented somewhere?

This is not documented, we just happen to know some things are wrong with document ID customization, but it's low priority so we haven't investigated yet.
Actually, we did not intend to provide any form of customization on the document ID, and it has been added almost by accident. Which is why we don't recommend to do it, and we even plan to remove support for such customization in Hibernate Search 6.0 (HSEARCH-2543).

Are there any other important issues with a numeric document ID you did not mention?

None that I'm aware of, at least.

Marco Perazzo
January 12, 2017, 8:23 AM

Thanks for answering my questions. Knowing that, we should avoid making the Document ID numeric, but use a seperate numeric field instead in our project.

Besides that, I was not able to create a simple test case that reproduces the problem.
One other thing I figured out is that it is happening when the class in question gets validated via an @IndexedEmbedded annotation inside another class.
If I remove this @IndexedEmbedded annotation, everything is OK again.
But still, I cannot create a test case... there must be something more to it.
I'm not sure if this is worth to investigate further since the plans are to forbid customizing the document ID in future releases.

Yoann Rodière
January 12, 2017, 9:26 AM

Okay, I'll try to play around with IndexedEmbedded.

I'm not sure if this is worth to investigate further since the plans are to forbid customizing the document ID in future releases.

I tend to agree, though we still wouldn't want regressions on this "feature". Have you ever seen it work before? I.e. did you notice this bug when upgrading from an earlier version of Hibernate Search?

Marco Perazzo
January 12, 2017, 10:24 PM

I finally found the true root cause of the problem and created another issue because it has in fact nothing to do with abstract classes or inheritance (false suspicion I guess, the error message was very misleading!).
See https://hibernate.atlassian.net/browse/HSEARCH-2545.

This issue here can be closed now...

Yoann Rodière
January 13, 2017, 9:59 AM

Thanks for looking into this !
Closing this ticket and continuing the discussion on HSEARCH-2545.
I also created to address the lack of context in error messages.

Assignee

Yoann Rodière

Reporter

Marco Perazzo

Labels

None

Suitable for new contributors

None

Pull Request

None

Feedback Requested

None

Components

Affects versions

Priority

Major
Configure