Follow-up on HSEARCH-1404: we've had some trouble making the transition to an engine that would accept indexed types that are not POJOs (for instance JSON objects), because:
* this would require engine APIs (in particular) to be agnostic regarding the indexed type
* and unfortunately, these APIs are exposed in the ORM module, where we definitely want all APIs to accept {{Class<?>}} as an indexed type identifier
The most obvious solution to our predicament would be to isolate the ORM APIs from the engine APIs as much as we can, adding wrappers that would perform the convertion between {{Class<?>}} and {{IndexedTypeIdenfitier}} as necessary.
There may be some shared APIs from time to time; I'm thinking of APIs such as the one mentioned [in this comment|https://hibernate.atlassian.net/browse/HSEARCH-2498?focusedCommentId=89460&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-89460], where everything after {{.query(Animal.class)}} could be shared between ORM and Engine.
Let's also keep in mind that other integrators of Hibernate Search - such as Infinispan - would benefit from the "POJO mapping via annotations" mode but will not want to depend on Hibernate ORM.
For this reasons the actual code reading from annotation mapping to build a schema, the object graph navigation code, etc.. should still be included in {{hibernate-search-engine}} (practical choice) or in a new separate module. This requirement suggest that the SPI will not be entirely removed. |
|
