[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711?pag... ] Sanne Grinovero updated HSEARCH-711: ------------------------------------ Fix Version/s: (was: 4.0.0.Alpha1) 4.0.0.Alpha2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711?pag... ] Hardy Ferentschik updated HSEARCH-711: -------------------------------------- Summary: Review of @org.hibernate.search.annotations.Index parameters (was: Review of org.hibernate.search.annotations.Index API (token names, parameter composition)) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711?pag... ] Hardy Ferentschik updated HSEARCH-711: -------------------------------------- Description: 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. was: We're having Enum values labeled NO,TOKENIZED,UN_TOKENIZED,NO_NORMS,.. while 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711?pag... ] 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_? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711?pag... ] 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711?pag... ] Hardy Ferentschik updated HSEARCH-711: -------------------------------------- Description: We're having Enum values labeled _NO_, _TOKENIZED_, _UN_TOKENIZED_, _NO_NORMS_ for the _org.hibernate.search.annotations.Index_ enum 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. was: 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711?pag... ] Sanne Grinovero resolved HSEARCH-711. ------------------------------------- Resolution: Fixed -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira