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

[Sanne Grinovero]

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
>
>
>