This feels like a first draft could be implemented easily, so I'll tentatively target 6.0. Use case I have an application that sends data to a datastore, but this datastore is not a relational database or is not accessed through Hibernate ORM. I want similar functionality to hibernate-search-mapper-orm, and I am prepared to provide the change events myself. Potential solution We could just use the javabeans mapper, probably renamed. The only things that would be missing, in my opinion:
- Some way to configure the "model paradigm":
- tree/document: entities are trees and are not expected to have any association to other entities. This means reindexing resolvers are disabled, and we won't check for inverse side of associations.
- graph: similar to Hibernate ORM: entities are trees but are expected to have associations to other entities. This means reindexing resolvers are enabled and we will check for inverse side of associations.
Regarding the name: maybe rename it to hibernate-search-mapper-pojo? But that may create split packages with the pojo-base module, so maybe a different name? Later, we'll need more features:
- Allow users to configure their own loader for results. WARNING: In order to prepare for this, we need to make sure the search API uses selectEntities() by default (but fails, because there's no loader).
- Allow better projections from Elasticsearch
Optionally, we could go a step further and provide an API that specifically targets Elasticsearch. But maybe this should be a separate module, e.g. hibernate-search-standalone-elasticsearch? |