Hi Sanne, what you speak of in my opinion is a very very cool feature. Moreover server-side indexes (and remote dialect) are more suitable for Openshift applications.
Using standard javax.persistence.Index APIs could be a very nice alternative to avoid confusion with Hibernate Search client side usage. For the problem (B) maybe we can extend the API (adding a some non standard annotation, at least one for the analyze). I'm really interested in this development. Thank you. Fabio On Wed, Mar 14, 2018 at 12:52 PM, Sanne Grinovero <sa...@hibernate.org> wrote: > Hi all, > > this one is a very desirable feature, yet tricky as there's high > chances of ambiguity and confusion for end users. > > > # Infinispan Remote indexing > > Infinispan embeds the Hibernate Search engine, and uses it to index > data being inserted in any cache having indexing enabled. As you know > Infinispan can be used to store Java POJOs, which get serialized using > JBoss Marshalling - or encoded into Protobuf entries using Infinispan > Protostream as helper layer. > > Hibernate OGM supports both modes, one meant for "Infinispan Embedded" > and one for "Infinispan Remote" as that's what each encoding strategy > is suited for. > > > # Protobuf & indexing > > Protobuf is a well defined format with plenty of documentation which > focuses on a "schema" of the encoding; Hibernate OGM is able to > generate such schemas dynamically and will generate encoders and > decoders which follow the encoding guidelines for Java objects. > > The meta schema of protobuf is not super flexible, yet there's the > option of annotating the Protobuf schema elements using "annotations" > in comments. > Protostream allows inserting Hibernate Search annotations directly in > these comments and will use them to generate the server side indexing > configuration, implicitly also allowing such properties to be queried > using indexed. > > For example you might have this string literally within the comments: > "@Field(store = Store.YES, analyze = Analyze.YES)" > > A full example of schema can be found here [1]. > (The Infinispan documentation is a bit sparse on this as they > encourage people to use another code gen tool, best refer to tests as > examples when working for OGM) > > > # What should OGM users experience? > > A naive solution would be to allow people to use the Hibernate Search > annotations on their JPA entities, and we have OGM copy these into the > generated schema; there's a number of problems with that: > - not all such annotations "translate" equally well [2] > - there's a mismatch between JPA properties and underlying encoding fields > - if I run a FullTextQuery do I expect it to work remotely? > - what if I want to use Hibernate Search locally as well or instead? > - references to local classes obviously won't work (custom > fieldbridges, analyzers, etc..) > > An alternative is to look at these as "indexes" of the underlying > store, so we'd use them to hint the Infinispan server about user > provided hints such as those generated by `javax.persistence.Index`. > I do think this is the cleaner approach, yet has two drawbacks: > A- I guess ORM might implicitly generate some indexes in its metadata > which the user might not have explicitly asked; e.g. accelerate unique > constraints and foreign keys; it's possible these might not be as > useful as expected in the Infinispan case. > B- we won't be able to leverage the awesome full-text capabilities :-( > > I believe A is something we could ignore for now and revisit if > there's actual demand. > > B is also not urgent, yet disappointing limitation as this capability > is a distinguishing feature of this NoSQL. Would we agree that > exposing such full-text capabilities would best be let to an ad-hoc > backend in Hibernate Search 6? > > > Thanks, > Sanne > > 1 - http://blog.infinispan.org/2018/02/restful-queries- > coming-to-infinispan-92.html > 2 - https://github.com/infinispan/infinispan/blob/master/remote- > query/remote-query-server/src/main/java/org/infinispan/ > query/remote/impl/indexing/IndexingMetadataCreator.java#L31 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev