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

[Jason Eacott (JIRA)]

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

Jason Eacott edited comment on HSEARCH-572 at 8/16/10 8:29 PM:
---------------------------------------------------------------

well in a totally naïve sense instead of this: 
{noformat}
final String propertyName = name + "." + entry.getKey();
final String propertyValue = entry.getValue().toString();
luceneOptions.addFieldToDocument( propertyName, propertyValue, document )
{noformat}

I'd need to store an actual NumericField, so would need to use the factory to generate them.
eg something like
{noformat}
float d = scanner.nextFloat();
document.add(new NumericField(propertyName, luceneOptions.getStore(),false).setFloatValue(d));
{noformat}
how should I do this without luceneOptions.getStore()?

As for how best to support Numeric and Spatial fields I do have some suggestions.
1. since hsearch is already heavily annotation based you should probably add support for a field type mapping on any as an annotation.
eg @Field(name="headers", index=Index.TOKENIZED, store=Store.NO, type=Numeric.Float)
however that would not help me for my map case.

for a map I think it is simplest if a field type can be identified by name. ie: somewhere a definition like this should be user definable (you could do it as an annotation per map but that would be painful, also I'm not a big fan of annotations for this kind of thing anyway)
{noformat}
<dynamicField name="*_i" type="integer" indexed="true" stored="true"/>
<dynamicField name="*_f" type="float" indexed="true" stored="true"/>
<dynamicField name="*_tri" type="tint" indexed="true" stored="true"/>
<dynamicField name="*_trf" type="tfloat" indexed="true" stored="true"/>
{noformat}
the actual logic for the indexing and queryparser can be taken from solr, but this approach does make constructing queries by api quite cumbersome. Lucene should be able to tell us which fields are which, but for now I think you have to maintain your own FieldType objects (just as solr does).

      was (Author: jeacott):
    well in a totally naive sense instead of this: 
{noformat}
final String propertyName = name + "." + entry.getKey();
final String propertyValue = entry.getValue().toString();
luceneOptions.addFieldToDocument( propertyName, propertyValue, document )
{noformat}

I'd need to store an actual NumericField, so would need to use the factory to generate them.
eg something like
{noformat}
float d = scanner.nextFloat();
document.add(new NumericField(propertyName, luceneOptions.getStore(),false).setFloatValue(d));
{noformat}
how should I do this without luceneOptions.getStore()?

As for how best to support Numeric and Spatial fields I do have some suggestions.
1. since hsearch is already heavily annotation based you should probably add support for a field type mapping on any as an annotation.
eg @Field(name="headers", index=Index.TOKENIZED, store=Store.NO, type=Numeric.Float)
however that would not help me for my map case.

for a map I think it is simplest if a field type can be identified by name. ie: somewhere a definition like this should be user definable (you could do it as an annotation per map but that would be painful, also I'm not a big fan of annotations for this kind of thing anyway)
{noformat}
<dynamicField name="*_i" type="integer" indexed="true" stored="true"/>
<dynamicField name="*_f" type="float" indexed="true" stored="true"/>
<dynamicField name="*_tri" type="tint" indexed="true" stored="true"/>
<dynamicField name="*_trf" type="tfloat" indexed="true" stored="true"/>
{noformat}
the actual logic for the indexing and queryparser can be taken from solr, but this approach does make constructing queries by api quite cumbersome. Lucene should be able to tell us which fields are which, but for now I think you have to maintain your own FieldType objects (just as solr does).
  
> 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
>          Components: mapping
>            Reporter: Jason Eacott
>            Assignee: Emmanuel Bernard
>             Fix For: 3.3.0
>
>
> 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