[ https://issues.apache.org/jira/browse/CAY-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17128465#comment-17128465 ]
Matt Watson commented on CAY-2660: ---------------------------------- Nice fix. Been needing this for a while. > BigDecimals that differ only in scale are treated as different values causing > unneeded updates > ---------------------------------------------------------------------------------------------- > > Key: CAY-2660 > URL: https://issues.apache.org/jira/browse/CAY-2660 > Project: Cayenne > Issue Type: Bug > Affects Versions: 4.0.2, 4.1.RC2, 4.2.M1 > Reporter: Andrus Adamchik > Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Given a column mapping of "DECIMAL(N, M)" to Java BigDecimal, the following > code causes an update where it shouldn't (as there are no changes) : > {noformat} > // assuming the column is "DECIMAL(12, 6)" > BigDecimal bd = new BigDecimal("7890.1"); > // save object > o.setValue(bd); > o.getObjectContext().commitChanges(); > // refetch object - the result will be padded to DB scale - "7890.100000" > BigDecimalEntity o2 = > ObjectSelect.query(BigDecimalEntity.class).selectFirst(runtime.newContext()); > // set to the same value and commit > o2.setValue(bd); > // *** PROBLEM HERE - "UPDATE" SQL is generated, while logically it should > have been a noop > o2.getObjectContext().commitChanges(); > {noformat} > [I have a PR|https://github.com/apache/cayenne/pull/426] with a fix based on > using "compareTo" instead of "equals" for BigDecimals, but it will require > some discussion... -- This message was sent by Atlassian Jira (v8.3.4#803005)