[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-572) a plea to reconsider deprecating luceneOptions.getStore(), luceneOptions.getIndex() etc

[Sanne Grinovero (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=38027#action_38027 ] 

Sanne Grinovero commented on HSEARCH-572:
-----------------------------------------

We certainly don't want to hide any useful Lucene feature behind the API, but when we choose this way - longly discussed - we thought that any bridge could still be written, but we might have been wrong. The idea is that in case of need you could avoid using addFieldToDocument(), which will apply the configured field options, and add fields to the Document directly.
Also using the addFieldToDocument serves to hide the eventually used compression.

The reason to lag behind the latest Lucene version was exactly this feature that we have been exposing the COMPRESS option in the past and so to prevent breaking backwards compatibility we had to stick to Lucene 2.9 for version 3.2 : removing these now deprecated methods paves the road to Lucene 3.0 (BTW if you don't make use of Compress you can use it already AFAIR)

Could you please attach an example of bridge, so we might discuss about a solution? BTW if you have the bridges to NumericFields ready these could be included in Search if you like.

> a plea to reconsider deprecating luceneOptions.getStore(), luceneOptions.getIndex() etc
> ---------------------------------------------------------------------------------------
>
>                 Key: HSEARCH-572
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-572
>             Project: Hibernate Search
>          Issue Type: Deprecation
>            Reporter: Jason Eacott
>
> Maybe I'm missing something, but for a fieldBridge I've noticed that it is now recommended to use luceneOptions.addFieldToDocument in place of document.add(new Field...
> This decision seems a bit overzealous and optimistic to me, especially given the current and significant lag in lucene version vs supported HibernateSearch version.
> for example - if luceneOptions.getStore(), luceneOptions.getIndex() etc are not deprecated then I can easily use them to create a custom field bridge for field types unknown to hibernateSearch. While these methods remain it is very easy to create a dynamic MapBridge for example that can choose to index a Map's key value pairs as Text or NumericFields as appropriate (Since HSearch currently has no support for NumericFields this is very useful). Without these methods, the options are much more limited. 
> So I'd just like to ask that either these methods remain, or an alternate arrangement be made available whereby any lucene field type can be added to a document with suitable index, store, boost, termvector etc. 
> Cheers.

-- 
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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira