[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-678) @NumericField does not work with BigDecimal types (and others?)

[Nick Fenwick (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=39819#action_39819 ] 

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/NumericField.html 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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira