There has been a critical change in Openbravo 2.50 public API to be released
in MP9 (November 30th, 2009). DAL implementation of columns referenced as
Number in the Aplication Dictionary are mapped now to BigDecimal intead of
Float. Getters and Setters for those columns are no longer using Float data
type but BigDecimal. For example, instead of
java.lang.Float
org.openbravo.model.common.currency.ConversionRate.getDivideRateBy()
now it is implemented as
java.math.BigDecimal
org.openbravo.model.common.currency.ConversionRate.getDivideRateBy()
Main reason for this change is that original API (using Float) was wrong:
arithmetic operations with Float properties might result in wrong results
since java can not represent float-point precisely
As a result, modules and customizations using DAL getters or setters of
columns with reference Number will need to be fixed before updating your
instances to MP9. The fix is quite simple: just replace the Float method (in
getters) or the Float parameter (in setters) by a BigDecimal one.
By November 15th 2009, from almost 100 published modules there are only
three affected by this API change:
- Invoice Register Book
- POS Sync Webservice
- IDL
- 347 report
The four of them will be fixed by Openbravo team and a new versions
including that fix will be published at the same time MP9 is published, so
updates applied from Central Repository -using scan for updates in Openbravo
Module Management window- will be transparently applied without errors.
Openbravo team will continuously monitor new published modules during the
next months to avoid an instance running MP9 or higher to use a module using
old API. We will keep all of you updated on our findings.
You have to take care about your not published modules. It is very simple to
check if your module is broken because of this change: update your
development instance to current pi repository -or to MP9 after publishing-
and build the system: the error will be clearly raised by your system.
Openbravo is strongly commited to keep its public API stable within major
versions but there is no point to keep stable something if it is wrong. We
have tried to minimize the pain by temporarily creating duplicated getters
and setters using both data types (Float and BigDecimal) and setting the
Float ones as deprecated to allow a gradual fix of the problem. But it is
not possible to have two methods with identical signature and different
return type and other approaches would have lead into a more painful
solution of the problem.
I apologize for inconvenience. This alert has been announced in Openbravo
Developers forum:
http://forge.openbravo.com/plugins/espforum/view.php?group_id=100&forumid=54
9512&topicid=7005952
Please monitor that thread to keep updated on the issue.
Thanks,
Ismael
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Openbravo-development mailing list
Openbravo-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbravo-development