[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-711) Review of @org.hibernate.search.annotations.Index parameters

Hardy Ferentschik (JIRA) noreply at atlassian.com
Sun Sep 11 12:30:02 EDT 2011


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

Hardy Ferentschik commented on HSEARCH-711:
-------------------------------------------

It seems we want to add ANALYZED_NO_NORMS (if for nothing else than completeness). Splitting into four parameters makes sense to me - _index_, _analyze_, _norms_ and _store_ (all _YES_, _NO_ options). _index=NO_ with _analyze_ or _norms_ set to _YES_ would log a warning. 
Of course this will break backward compatibility. We cannot just deprecate the existing behavior. But 4.0 is supposed to be the release were we do it.   

> Review of @org.hibernate.search.annotations.Index parameters
> ------------------------------------------------------------
>
>                 Key: HSEARCH-711
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711
>             Project: Hibernate Search
>          Issue Type: Deprecation
>            Reporter: Sanne Grinovero
>            Assignee: Hardy Ferentschik
>             Fix For: 4.0.0.Beta1
>
>
> We're having Enum values labeled _NO_, _TOKENIZED_, _UN_TOKENIZED_, _NO_NORMS_, ...
> Lucene changed these names to more suited "analyzed", "not_analyzed", etc.
> Also I think it would be great to use an array of parameters instead of an enum listing all options, or maybe split the option in two:
> {code}
> @Field({ANALYZE,NO_NORMS})
> {code}
> or
> {code}
> @Field(analyze=YES,norms=NO)
> {code}
> We should at least deprecate current names and use the more appropriate terms.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the hibernate-issues mailing list