[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-711) Review of @org.hibernate.search.annotations.Index parameters
Hardy Ferentschik (JIRA)
noreply at atlassian.com
Fri Sep 9 11:47:02 EDT 2011
[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43491#comment-43491 ]
Hardy Ferentschik commented on HSEARCH-711:
-------------------------------------------
I kind of liked the idea of splitting out the _norm_ parameter, but it causes some questions. For example, how do you handle _Index.NO_ if you just have _analyze_ and _norms_? You also have _index_ (YES, NO)? And if you go down this path what do you do in cases of _index=NO_ + _analyze=YES_ - ignore, log warning, error!?
Out of interest, why do we currently not have an equivalent for _org.apache.lucene.document.Field.Index.ANALYZED_NO_NORMS_ in _org.hibernate.search.annotations.Index_?
> 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
> 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