[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-572?pag...
]
Emmanuel Bernard commented on HSEARCH-572:
------------------------------------------
I've undeprecated the methods and heavily insisted on not using the methods.
This API might change a tiny bit with HSEARCH-434 (NumericField support).
{code}
/**
* A helper class for building Field objects and associating them to Documents.
* A wrapper class for Lucene parameters needed for indexing.
*
* The recommended approach to index is to use {@link #addFieldToDocument(String, String,
org.apache.lucene.document.Document)}
* as all the options delcared by the user are transparently carried over. Compression is
also provided transparently.
*
* String fieldValue = convertToString(value);
* luceneOptions.addFieldToDocument(name, fieldValue, document);
*
*
* @author Emmanuel Bernard
* @author Sanne Grinovero
* @author Hardy Ferentschik
*/
public interface LuceneOptions {
/**
* Add a new field with the name {@code fieldName} to the Lucene Document {@code
document} using the value
* {@code indexedString}.
* If the indexedString is null then the field is not added to the document.
*
* The field options are following the user declaration:
* - stored or not
* - compressed or not
* - what type of indexing strategy
* - what type of term vector strategy
*
* @param fieldName The field name
* @param indexedString The value to index
* @param document the document to which to add the the new field
*/
void addFieldToDocument(String fieldName, String indexedString, Document document);
/**
* Prefer the use of {@link #addFieldToDocument(String, String,
org.apache.lucene.document.Document)}
* over manually building your Field objects and adding them to the Document.
*
* To use compression either use #addFieldToDocument or refer
* to Lucene documentation to implement your own compression
* strategy.
*
* @return the compression strategy declared by the user {@code true} if the field value
is compressed, {@code false} otherwise.
*/
boolean isCompressed();
/**
* Prefer the use of {@link #addFieldToDocument(String, String,
org.apache.lucene.document.Document)}
* over manually building your Field objects and adding them to the Document.
*
* Return the storage strategy declared by the user
* {@code org.apache.lucene.document.Field.Store.YES} if the field is stored
* {@code org.apache.lucene.document.Field.Store.NO} otherwise.
*
* To determine if the field must be compressed, use {@link #isCompressed()}.
*
* Starting from version 3.3, Store.COMPRESS is no longer returned, use {@link
#isCompressed()}
*
* To use compression either use #addFieldToDocument or refer
* to Lucene documentation to implement your own compression
* strategy.
*/
Field.Store getStore();
/**
* Prefer the use of {@link #addFieldToDocument(String, String,
org.apache.lucene.document.Document)}
* over manually building your Field objects and adding them to the Document.
*
* Return the indexing strategy declared by the user
*/
Field.Index getIndex();
/**
* Prefer the use of {@link #addFieldToDocument(String, String,
org.apache.lucene.document.Document)}
* over manually building your Field objects and adding them to the Document.
*
* Return the term vector strategy declared by the user
*/
Field.TermVector getTermVector();
/**
* Prefer the use of {@link #addFieldToDocument(String, String,
org.apache.lucene.document.Document)}
* over manually building your Field objects and adding them to the Document.
*
* Return the boost factor declared by the user
*/
Float getBoost();
}
{code}
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.Beta2
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira