[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-763?pag... ] Sanne Grinovero commented on HSEARCH-763: ----------------------------------------- Main reason to open this issue was to track the decisions taken in mail having subject "[hibernate-dev] Hibernate Search 3.5 or 4". I wrote this proposal and nobody seemed to comment about this point, so maybe it wasn't clear enough. I think it makes sense as this is a better approach both for a) sorting (doesn't require padding, so works out of the box) b) range queries. I'm not aware of drawbacks of using them, but maybe there is some reason to still use a traditionally string-encoded number? It's known that NumericFields use slightly more space, but being this a possible performance optimization with some drawbacks I'd assume that by default it should take this space. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-763?pag... ] Sanne Grinovero updated HSEARCH-763: ------------------------------------ Suitable for new contributors: [Yes, likely] -- 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-763?pag... ] Sanne Grinovero commented on HSEARCH-763: ----------------------------------------- I still think it would be nice to have it applied by default, but @NumericField needs a "precision" option. Can we define good default for these ? Otherwise this issue is a bit pointless. -- 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-763?pag... ] Hardy Ferentschik commented on HSEARCH-763: ------------------------------------------- {quote} * support older application without breaking them (maybe a global flag is appropriate) * how will people be able to use the old non-numeric fields? by explicitly providing a field bridge? {quote} and the documentation must be clearly aligned (obviously) -- 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-763?pag... ] Sanne Grinovero updated HSEARCH-763: ------------------------------------ Fix Version/s: (was: 4.0.0.Beta2) 4.0.0.CR1 -- 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-763?pag... ] Emmanuel Bernard updated HSEARCH-763: ------------------------------------- Fix Version/s: (was: 4.0.0.Final) No decision. Dropping it off 4.0. The likelihood is a global flag at some point which can be backward compatible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira