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(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
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev