Sanne, Is there any news on where we stand with this?
I saw you discussed and moved some issues to HSEARCH 5; Does that mean we have everything in place now for the ISPN use case? I'd have assumed at least making the OBJECT_CLASS (HSEARCH-1402) field user-writable would be needed for restricting queries to specific "user types", but this one has been moved to 5 as well. Thanks, --Gunnar 2013/9/20 Gunnar Morling <gun...@hibernate.org> > Hi, > > I'm beginning to wonder which of these things we actually do need in 4.4 > to satisfy the requirements of ISPN remote queries. At the moment we have: > > * the ability to index "user types" via one generic "value holder type" > using a smart class bridge which adds all the required fields; with > HSEARCH-1396 [1] we allow for passing bridge _instances_ to the engine > which e.g. enables to inject the user type configuration (which fields > required) into this class bridge by the client > > * the ability to query the properties of a user type by allowing to > specify the bridges to be used for given fields (HSEARCH-1409 [2], PR is > opened [3]); In particular this allows to query against fields which are > not statically declared for the value holder type > > > 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. > > I think this part is still missing. I'm wondering though whether it > couldn't be emulated "well enough" by making the > ProjectionConstants.OBJECT_CLASS field user-writable (as suggested with > HSEARCH-1402) and querying on this field? Together with the dynamic > sharding work from Hardy also the "separate backends for each user type" > part might be addressed by assigning each user type to a separate shard of > the value holder type's index. > > If this is feasible, it would allow to stick to the class-based design for > the time being. This might help with limiting the number of changes > required to be delivered with 4.4 and focus on implementing the dynamic > entity feature properly in HSearch 5. Any thoughts? > > --Gunnar > > [1] https://hibernate.atlassian.net/browse/HSEARCH-1396 > [2] https://hibernate.atlassian.net/browse/HSEARCH-1409 > [3] https://github.com/hibernate/hibernate-search/pull/486 > > > 2013/9/11 Sanne Grinovero <sa...@hibernate.org> > >> 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 >> > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
