[hibernate-dev] Required improvements for Infinispan's query engine

[Adrian Nistor]

Hi Gunnar,

I'm using a single generic entity to represent multiple domain entities 
in the context of a single SearchFactory. So it seems we fall into the 
more complex case of "more abstract representation of types than class 
objects". Is this still doable in hsearch? I'm keeping my fingers 
crossed this 'a bit large change' does not mean a huge impossible change 
in this version.

The code is here:
https://github.com/infinispan/infinispan/tree/master/remote-query/remote-query-server/src/main/java/org/infinispan/query/remote/indexing
https://github.com/infinispan/infinispan/tree/master/remote-query/remote-query-server/src/main/java/org/infinispan/query/remote/search

Cheers,
Adrian

On 09/10/2013 11:28 AM, Gunnar Morling wrote:
> 2013/9/9 Adrian Nistor <anistor at redhat.com <mailto:anistor at redhat.com>>
>
>     Hi Gunnar,
>
>     I currently use a single generic indexed entity which represents
>     the multitude of protobuf defined domain types. This approach is
>     not necessarily ideal but was forced to adopt it because of the
>     way hsearch currently works. Other projects do the same (ModeShape
>     is one such example).
>
>
> Do you have a pointer for me where I can find your code integrating 
> with the parser? What I'm trying to find out is whether your 
> GenericEntity is used to map several of your ProtoBuf domain types in 
> the context of one SearchFactory instance or not.
>
> If this the case, the SPI would need to work with a more abstract 
> representation of types than class objects, e.g. 
> getFieldBridge("com.example.MyDomainEntity", "myProperty") and also 
> the changes within HSEARCH will be a bit larger. If GenericEntity 
> represented always exactly one domain type in the context of one 
> SearchFactory instance, we could have the SPI look like 
> getFieldBridge(GenericEntity.class, "myProperty"), and hooking things 
> into HSEARCH would become a bit simpler.
>
>
>     Having an SPI so I can provide my own field bridges seems like a
>     good idea that would solve my current needs.
>
>     Thanks,
>     Adrian
>
>
>     On 09/08/2013 02:33 PM, Gunnar Morling wrote:
>>     Hi Adrian,
>>
>>     We have been contemplating some ideas around your requirements.
>>     Are you working with several "types" (as defined by ProtoBuf
>>     files) or only one such type per one of your caches (and thus
>>     afaics SearchFactory)?
>>
>>     In case of the latter, one idea would be that you always target
>>     your generic entity type with your queries and we provide an SPI
>>     which allows you to configure the field bridges to be applied for
>>     the individual fields of a given entity (here always the generic
>>     entity type), e.g.  FieldBridge getFieldBridge(Class<?> type,
>>     String fieldName). We could then query this SPI from within the
>>     HSEARCH-based parser backend to apply the right field bridges for
>>     a given query. You would create any FieldBridge instances
>>     yourself and thus could inject whatever data you need into them.
>>
>>     Would this address the needs of Infinispan?
>>
>>     If you need to work with several ProtoBuf types per
>>     SearchFactory, we'd have to do some more changes within HSEARCH,
>>     as the metadata essentially is keyed by class type atm. and we'd
>>     have to change that to key by a more type representation.
>>
>>     Thanks,
>>
>>     --Gunnar
>>
>>
>>     2013/8/31 Emmanuel Bernard <emmanuel at hibernate.org
>>     <mailto:emmanuel at hibernate.org>>
>>
>>         Adrian found a few problematic limitations in Hibernate
>>         Search during
>>         its integration of the HQL query parser and the Hibernate
>>         Search back
>>         end.
>>
>>         Composite bridge::
>>         https://hibernate.atlassian.net/browse/HSEARCH-1397
>>
>>         Injection of services into a FieldBridge::
>>         https://hibernate.atlassian.net/browse/HSEARCH-1396
>>
>>         These two are important for Infinispan 6 and should be give
>>         priority.
>>         I think they can be added in 4.4 without too much effort.
>>
>>         Thoughts?
>>
>>         Otherwise, support for mapping non Java object structures is
>>         something
>>         we should do in Hibernate Search. For 5?
>>         Is there a JIRA for it?
>>
>>         Emmanuel
>>
>>         _______________________________________________
>>         hibernate-dev mailing list
>>         hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>
>