Some other projects use Hibernate Search - specifically the engine module - to bridge their domain model to a Lucene index and take advantage of its high performance low-level integration with Lucene. This is generally achieved by indexing a "valueholder" object which has most logic to create a custom o.a.l.Document in a top level @ClassBridge, or by using some custom FieldBridges, but has some strong limitations and feels more like a hack.
In Hibernate Search 5.0 we will make this more flexible, so to move away from an annotated-entities index engine only to make it easier to index objects whose "schema" is more flexible than the contraints imposed by the staticness of a compiled Java class. We've discussed however to introduce some of these features right now (in version 4.4), so that we can start exploring the direction gradually and get some early feedback. In particular what seems to be troublesome is to implement multiple "user types" using the same type (java type) as valueholders: the trouble is to filter on the correct user type where the Hibernate Search APIs expect - as basic filtering strategy - a java Class instance, or simply to have the flexibility to configure separate backends for each user type. So this first refactoring [HSEARCH-1402] will be about moving the *internal* contract - without changing public APIs - to use a different identification than the current Class when we lookup for indexing information for a specific indexed type. Comments very welcome. Sanne - https://hibernate.atlassian.net/browse/HSEARCH-1379 Explicit support for indexing free-form (dynamic) entities - https://hibernate.atlassian.net/browse/HSEARCH-1402 Allow explicit user control of ProjectionConstants.OBJECT_CLASS value during indexing - https://hibernate.atlassian.net/browse/HSEARCH-1404 More flexibility than just Class to identify indexing metadata _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
