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

[Emmanuel Bernard (JIRA)]

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

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