image

ADF allows you to specify formatting (format type and value) for a BigDecimal typed attribute on an entity object or on view object. What is the big deal in it? Well nothing great here :) My intention is different, want to discuss a row inconsistency error that you may see in this context. When you modify the above mentioned attribute value twice in a transaction from the ADF Faces UI, you may notice RowInconsistentException exception(i.e modify the formatted BigDecimal value from UI,  commit the transaction and then modify same value again and try committing it). This error says the row that you are currently updating is having stale value - in other words another user has modified the row while you were making some changes. However the actual reason for this error  is due to the fact  that BigDecimal::equals() method compares both value and scale, so 5.00 is not same as 5.  This result in the RowInconsistentException when framework tries to to compare originally read value for the attribute with latest value from DB.

A work around solution is to make the run time to use BigDecimal::compareTo() method while performing consistency check. This method compares the value alone while comparing two objects. The place where you add this piece is OracleSQLBuilderImpl::compareFetchedValue(...) method, which can be done by customizing the default SQL builder class . The following blog may help you to understand how to add your custom SQL builder to an application module: http://www.jobinesh.com/2013/02/customizing-sql-builder-class.html

Download

You can download the sample workspace from here. Take a look at the model.ContextAwareOracleSQLBuilderImpl class in the Model project to get a feel of the custom SQL builder class that we discussed a while back. Also see the bc4j.xcfg file in the model project where the custom sql builder is configured by specifying appropriate values for jbo.SQLBuilderClass and  jbo.SQLBuilderClass properties.
[Runs with Oracle JDeveloper 12.1.2.0.0 or higher + HR Schema]