it could be done, but generally I see some problems with it: - the API should make it very clear that these are unmanaged and detached entities: * they are out of transactions * navigating lazy loaded properties is not going to work * changes made to these objects will not be synchronised back to the index nor to the database - we only store in the index the minimal set of fields required, as mapped explicitly by the user * we won't be able to load any field not mapped as @Field & Stored.YES * Making extended use of Stored.YES is not to be advised: it bloats the index making it larger than needed and slower - extracting fields from Stored fields is performance intensive: usually a database can do better than that, especially with 2nd level cache
I would advise to make a constructor for your entities which takes the Object[] returned from a projection: that is not too different than what we would have to do, but at least you do it explicitly and are aware of the limitations. I suspect that you could address them better than with a general purpose solution, but you're very welcome to provide suggestions.
Usually what people do on very performance sensitive areas is to use combine it with a 2nd level cache: nothing beats the performance of a map lookup; you can combine fulltext queries with 2nd level cache interaction by using ObjectLookupMethod as described in chapter: 5.1.3.6. Customizing object initialization strategies
http://docs.jboss.org/hibernate/search/4.2/reference/en-US/html_single/
Please le me know how it goes, it would be interesting to explore new strategies if needed.
_________________ Sanne http://in.relation.to/
|