You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Andrus Adamchik (Jira)" <ji...@apache.org> on 2020/06/05 12:33:00 UTC
[jira] [Updated] (CAY-2660) Zero padding of BigDecimals causes
unneeded updates
[ 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 with a fix (to be sent shortly), but it may 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());
o2.setValue(bd);
// THIS COMMIT GENERATES AN "UPDATE" SQL, where it should have been a noop
o2.getObjectContext().commitChanges();
{noformat}
I have a PR with a fix (to be sent shortly), but it may require some discussion...
> Zero padding of BigDecimals causes 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
>
> 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), but it may require some discussion...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)