[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-711) Review of @org.hibernate.search.annotations.Index parameters
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711?pag...
]
Sanne Grinovero commented on HSEARCH-711:
-----------------------------------------
bq. 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?
I implemented it but then asked the community to provide a test: HSEARCH-710 Apparently
not a priority for anybody.
bq. 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!?
Not sure.. I'd log a warning.
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