[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-425) Reimplement support for compressed fields (support removed in Lucene3)

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-425?pag... ] Sanne Grinovero commented on HSEARCH-425: ----------------------------------------- I have been playing around with it, no matter what something has to break: there's no point in the current code where we can "intercept" what fieldbridges do. I am attaching a patch which is using a totally new use for the org.hibernate.search.bridge.LuceneOptions (if we go this way it might as well change name), in which the default impl will hide the COMPRESS complexity - making it possible to eventually plug a custom strategy in future or change some logic while hiding it from API. This is just a POC to get some thoughts on the table - no tests. What should we do with existing getters in the Interface? @deprecate or remove? Deprecation is not totally safe here as behavior will be different, but still it might look like the same (as Lucene is transparently decompressing..) A nice side effect from the proposed signature is that code in the bridges is much simplified (have a look at all lines removed from test bridges) and some optimizations like "skip for empty string" are applied consistently. Didn't play with decompress yet: still wondering if above proposal is not viable if we shouldn't remove the feature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira