NOTE: This is probably at least partially addressed by the mapper-javabean module, which as of is not published to Maven repositories.
The idea is to offer a layer that simplify how to write ORM or Infinispan style integration.
The source of change events becomes an explicit call of this new API.
The target audience is for example CRUD (or more evolved) (micro)services that want to index data on each C_UD operation and have the ability to write full-text queries and retrieve the entities.
> Actually ORM does expose add/update/delete but via the JPA methods like persist / merge / remove.
Haha . I haven only used the JPA interfaces of Hibernate, yet.
About the hierarchical entities:
I don't really know what is needed to support that or what has to be changed, but in my opinion that would be a relevant feature (at least for my implementation).
I don't know all the things necessary for my implementation yet since I am not finished with designing. I think I can provide you at least with some details later this week.
Well Hibernate has saveOrUpdate / save / update, so it's the same
On the hierarchy, I think I know what to do, it's somewhat similar to the delete by term optimization I did. It's hard and a subtle contract which I'm not sure we want to expose at that level.
It doe snot seem to be clear from a few conversations I have seen. This API targets end developers, not integrators. A typical use case is the following.
I have a microservice storing data in a specific backend not covered with a native Hibernate Search integration. I would use this explicit API to enable my full-text search.
Moving to Search 6.
Most of the infrastructure necessary to integrate an even source/datastore other than Hibernate ORM is already available in Search 6. You simply need to write a custom mapper derived from the POJO mapper.
However, it seems this ticket is supposed to benefit to Hibernate Search users, not integrators.
If so, we need to make things simpler in Search 6, or at least add documentation about how to write a (simple) mapper.
This feels like a first draft could be implemented easily, so I'll tentatively target 6.0.
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.
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?