[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711?pag...
]
Sanne Grinovero commented on HSEARCH-711:
-----------------------------------------
{quote}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.
{quote}
+1
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