| 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/
 
 
 |