Isn’t the @Id + @Embeddable approach to composite keys valid anymore? It’s been working ok so far.
Ok, I didn’t know about this syntax. It may be supported for historical reasons, since it doesn’t seem to be part of the JPA spec. The fact that you had to look for Hibernate 3.5 documentation to find an example seems to check out
@EmbeddedId would probably be more portable, but yes, if it works, it works.
Regarding the technical ID or composite/natural key problem the accepted answer to the StackOverflow question you mentioned is spot on in my opinion. But if I were you, I wouldn’t worry too much about performance in this case: I mentioned it, but it’s not the main problem. The main problem is how cumbersome composite keys are in general, but especially if they include an association.
You just experienced it with Hibernate Search: having to retrieve an entity in order to build the primary key of another entity is quite annoying. And I’m sure this is not the end of it: when handling parameters to a web page, when exporting data to other systems (in JSON, XML) and receiving data back, …
The thing is, with a technical ID + unique constraint, you will have the choice: you can still retrieve entities by some unique, composite key even if it’s not their primary key. Without a technical ID, you don’t have any choice.
As to “Is the Hibernate recommendation to always use the former [technical IDs instead of composite/natural IDs]?”, I wouldn’t speak for the Hibernate ORM guys, but maybe @vlad can give you an answer.
(wondering if this distinct-like filtering could be achieved at the Hibernate Search level)
The distinct-like filtering cannot be achieved at the Hibernate Search level at the moment. In order to work properly with paging it would require non-trivial pre-processing during search (aggregations), which we didn’t have time to work on yet. It doesn’t seem to be solvable in Elasticsearch, but we’ll have to look into it. You can follow progress on the aggregation topic on HSEARCH-3003 and progress on the “distinct” topic on HSEARCH-868.
Regarding the nested documents, we are aware that Hibernate Search lacks such support, and they are being implemented for both the Lucene integration and the Elasticsearch integration in Hibernate Search 6. So hopefully this should not be a problem anymore when Hibernate Search 6 is out (which should still take some time). In the meantime, your analysis and solution are correct: you’ll have to reverse the index.
There is only one other potential solution you could try, but it is a bit hackish and cannot always be applied: if you know you will have to look for two properties at the same time, and know there is a character that does not appear in either property, you can simply index the concatenation of
property1 + '<the character>' + property2. A bit hackish, like I said, and clearly not a solution to every problem.
So to answer your original question:
Is retrieving SomeOtherEntity instances in the stringToObject method an acceptable approach?
Yes it’s acceptable if it works (which mostly depend on
SomeOtherEntity.findById using the right entity manager). Performance may be worse than with IDs that do not contain any association. Technical IDs would be less trouble, though.