To be implemented after HSEARCH-3296, because that ticket will make sure the entry point for this new API are present.
We should add an API allowing to declare what changes will trigger reindexing of a given bridged element because of what a bridge uses in that bridged element. The API would be an unsafe alternative to the current accessor API (still experimental), but more powerful and far easier for us to implement.
Essentially the idea would be to declare dependencies starting from the entity that should trigger reindexing: {{depModel.type( A.class ).onChangeOf( c -> c.property( "child" ) ).thenReindex( c -> c.property( "parent" ) )}} would mean "when property 'child' on type A is modified, then reindex the entity in property 'parent'" the following function to collect all the entities that should be reindexed".
This API should allow to refer to property paths up to the entity boundaries (i.e. {{.onType( A.class ).property("someEmbeddable").property("someProperty")}}, but not {{.onType( A.class ).property("someEntity").property("someProperty")}}.
Also, this should allow the use of container value extractors, i.e. {{.onType( A.class ).property("someEmbeddable", CollectionElementExtractor.class )}} and maybe also a simpler, more limited syntax such as {{.onType( A.class ).collectionProperty("someEmbeddable" )}}.
As a first step, this API should only be enabled when the bridged element is an entity. Embeddables may be a bit tricky to support, so let's throw exceptions when the users attempts to use the API on non-entity bridged elements for now.
h3. Going further
h4. Implicit declaration
We may also decide to allow to declare dependencies "implicitly", by declaring which properties of the bridged element will be used by the bridge. Then an algorithm (already implemented) would deduce the reindexing process.
This would however be very similar to the "accessor" API. It would be much easier for us to implement, but still limited to a subset of all use cases, and also a bit confusing for users since it would duplicate the "accessor" API.
h4. Function-based reindexing collector
Instead of forcing the user to declare the path to the entities to reindex, just let him provide a function that will collect the entities for us.
{ { code}
depModel.type( A.class ).onChangeOf( c -> c.property( "child" ) ).thenReindexCollected( a -> a.getParent() )
{code } }
... which is essentially what was drafted here: https://github.com/hibernate/hibernate-search-6-poc/commit/8a4fcca27e329e90c9c8be123f7143b6f0961c8c#diff-30992751bb082af82e3dc1df4452cb9fR53
This could be much more powerful than the declarative version, since it could allow to support paths of arbitrary length, unbounded at bootstrapping time (e.g. {{.a.a.a.a.a.a.a...}} until a certain condition is met).
h4. Query-based reindexing collector
See HSEARCH-1937 |
|
