[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-678?pag...
]
Nick Fenwick commented on HSEARCH-678:
--------------------------------------
Thanks for looking into it. This sounds a bit crazy, because what I've read recently
states that BigDecimal is the best way to represent financial data in a Java application.
It seems to be, on the surface, fairly trivial to bridge a BigDecimal field to a string
representation, for storage in a Lucene index in a way that Lucene can treat as a
@NumericField, and store in a Trie structure, with all the speed optimisations that come
with that special handling. Surely this is worth pursuing?
If you are certain we have no way of doing this, please advise in your doc update how one
should encode financial data using Hibernate Search. I feel a lot of users will come to
this situation, as I have, wanting to use BigDecimal as their Entity attribute types, and
wanting the Trie optimisations provided by @NumericField, needing a good solution.
From my point of view, the NumericField javadoc at
http://lucene.apache.org/java/3_0_3/api/core/org/apache/lucene/document/N...
states that int, long, float and double are directly supported, so couldn't we provide
a solution that turns a BigDecimal into a long representation by multiplying by its scale,
such that 12.34 is stored in lucene as 1234?
@NumericField does not work with BigDecimal types (and others?)
---------------------------------------------------------------
Key: HSEARCH-678
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-678
Project: Hibernate Search
Issue Type: Bug
Components: mapping, query
Affects Versions: 3.3.0.Final
Environment: Hibernate 3.6.0, MySQL 5.1.52, Fedora Core 14
Reporter: Nick Fenwick
Assignee: G Fernandes
Fix For: 3.4.0
Attachments: HSEARCH-678-unittest1.tgz
This is my first JIRA so please help me assigns its Component above correctly.
My first attempt to use BigDecimal ran into trouble trying to use the new @NumericField
annotation. The SessionFactory fails to create an instance of the session. The code:
{{
@Column(name="val")
@Field(name="val", index=Index.UN_TOKENIZED, store=Store.YES)
@NumericField
private BigDecimal val;
}}
Results in the exception:
{{
Exception in thread "main" java.lang.ExceptionInInitializerError
[cut]
Caused by: org.hibernate.HibernateException: could not init listeners
[cut]
Caused by: org.hibernate.search.SearchException: Unable to guess FieldBridge for val
at org.hibernate.search.bridge.BridgeFactory.guessType(BridgeFactory.java:250)
at
org.hibernate.search.engine.AbstractDocumentBuilder.bindFieldAnnotation(AbstractDocumentBuilder.java:690)
at
org.hibernate.search.engine.AbstractDocumentBuilder.checkForField(AbstractDocumentBuilder.java:564)
[cut]
}}
Taking out the @NumericField allows the session to start up successfully.
I will attempt to make a test case but I'm having local build env issues. 'mvn
clean install' of a fresh hibernate search git checkout is taking an incredibly long
time (an hour for the first 10 or so .pom files?) so I may be several hours or days over
this trivial task.
--
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