forwarding this to the list too (hoping this time is not rejected by
-------- Original Message --------
Subject: Re: [hibernate-dev] Required improvements for Infinispan's
Date: Mon, 09 Sep 2013 17:06:14 +0300
From: Adrian Nistor <anistor(a)redhat.com>
To: Gunnar Morling <gunnar(a)hibernate.org>
CC: Hibernate Dev <hibernate-dev(a)lists.jboss.org>, Emmanuel Bernard
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).
Having an SPI so I can provide my own field bridges seems like a good
idea that would solve my current needs.
On 09/08/2013 02:33 PM, Gunnar Morling wrote:
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.
2013/8/31 Emmanuel Bernard <emmanuel(a)hibernate.org
Adrian found a few problematic limitations in Hibernate Search during
its integration of the HQL query parser and the Hibernate Search back
Injection of services into a FieldBridge::
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.
Otherwise, support for mapping non Java object structures is something
we should do in Hibernate Search. For 5?
Is there a JIRA for it?
hibernate-dev mailing list