cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrus Adamchik (Jira)" <j...@apache.org>
Subject [jira] [Updated] (CAY-2660) BigDecimals that differ only in scale are treated as different values causing unneeded updates
Date Fri, 05 Jun 2020 13:01:00 GMT

     [ https://issues.apache.org/jira/browse/CAY-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrus Adamchik updated CAY-2660:
---------------------------------
    Description: 
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... 

  was:
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 with a fix (to be sent shortly) based on using "compareTo" instead of "equals"
for BigDecimals, but it will require some discussion... 


> 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)

Mime
View raw message