[hibernate-dev] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote

[Sanne Grinovero]

On 22 March 2018 at 15:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> As we discussed on the phone, I am skeptical of the custom HSearch backend
> for it:
> - it would be the only database doing that
> - it’s a lot of work that would probably be best spent improving the
> Infinispan remote query FT APIs
> - once there it will be a maintenance burden.

Thanks for clarifying. Then we won't create that in Search 6, at least
not until we have a better proposal.

The take away from this thread is that we don't want to map Hibernate
Search annotations from the domain model directly on the protobuf.

We can explore other ways to expose Infinispan's capabilities which
are less confusing.

Sanne

>
> Emmanuel
>
> On 22 Mar 2018, at 10:46, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> On 22 March 2018 at 07:41, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>
> On 20 Mar 2018, at 12:41, Sanne Grinovero <sanne at hibernate.org> wrote:
>
>
>
> On 20 March 2018 at 10:50, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>
> I think treating the client side HSearch input and transparently push it
> down is a recipe for disaster. Looks cool on paper until you have
> divergence between HSearch proper and Infinispan's or whatever
> Infinispan exposes.
>
>
>
> Looks like we agree on the premise, but you didn't comment on the proposal?
>
>
>
> I did, it’s right below :) Granted that’s an option C.
>
>
> /The/ proposal in my first email is to have an Hibernate Search 6
> "backend" to support Infinispan Remote.
>
> I see no comments on that, but it's ok since it looks like we agree on
> the problems I had already listed.
>
> Thanks,
> Sanne
>
>
>
>
>
> So yes we could have GridDialect specific metadata information around
> indexing but I would not reuse Hibernate Search annotations for that.
> Treat Infinispan like any of the other GridDialect providers.
>
> As for the way to express FTQ, then Infinispan needs to make Ickle more
> powerful.
>
> Emmanuel
>
>
> On Wed 18-03-14 11:52, Sanne Grinovero 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>