Project

General

Profile

Bug #10380

« Previous | Next »

WRITE-XML serializes decimals different than the specified format

Added by Teodor Gorghe 12 months ago. Updated 10 months ago.

Status:
Test
Priority:
Normal
Assignee:
Teodor Gorghe
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
Constantin Asofiei, Ovidiu Maxiniuc
production:
No
env_name:
topics:

History

#1 Updated by Teodor Gorghe 12 months ago

We have the following case:

DEFINE TEMP-TABLE tt1 NO-UNDO FIELD f1 AS DECIMAL DECIMALS 8 FORMAT "->>,>>>,>>9.99999999".
DEFINE DATASET ds1 FOR tt1.

CREATE tt1.
tt1.f1 = 0.
RELEASE tt1.

DATASET ds1:WRITE-XML ("longchar", cLongchar).

// FWD: The generated XML tt1.f1 node value is actually "OE-8" and it must be 0.00000000.
// READ-XML fails here because of "** Invalid character in numeric input E. (76)" 

DATASET ds1:READ-XML ("longchar", cLongchar, "empty", ?, ?). // FWD: This does not always fail, is dependent of the XML input!!

#3 Updated by Teodor Gorghe 12 months ago

  • Status changed from New to WIP
  • Assignee set to Teodor Gorghe

Created task branch 10380a.

#4 Updated by Teodor Gorghe 12 months ago

  • % Done changed from 0 to 100
  • Status changed from WIP to Review
  • reviewer Constantin Asofiei added

Committed revision 16088 on task branch 10380a:
- Replaced BigDecimal.toString to BigDecimal.toPlainString on writeDatum2 method.

#5 Updated by Teodor Gorghe 12 months ago

  • reviewer Ovidiu Maxiniuc added

Ovidiu, please review this change.
It is a small change which fixes serialization of decimal data type on WRITE-XML (uses the plain format instead of scientific format, when DECIMALS attribute is present into a field).

#6 Updated by Ovidiu Maxiniuc 12 months ago

  • Status changed from Review to Internal Test

Good catch! The fix is good. With it, I guess, the original issue is gone.

Due to its simplicity, basic regression tests should be enough. Assuming it passes, it can be queued for merging.

#7 Updated by Teodor Gorghe 12 months ago

Ovidiu Maxiniuc wrote:

Good catch! The fix is good. With it, I guess, the original issue is gone.

Due to its simplicity, basic regression tests should be enough. Assuming it passes, it can be queued for merging.

I have tested this task branch on several applications (harness and unit tests) and it seems right, there is no edge case which I might have thought on #10068-165 and it is safe.

This should be added into the merge queue after #10385 (as pointed on #10068-152).

#8 Updated by Constantin Asofiei 10 months ago

10380a rev 16089 - Ensure a leading '0' is added for decimal values when writing to XML, which are between zero and one. - so .123 is exported as 0.123

#9 Updated by Constantin Asofiei 10 months ago

Teodor, please merge after 9763c.

#10 Updated by Constantin Asofiei 10 months ago

  • Status changed from Internal Test to Merge Pending

#11 Updated by Teodor Gorghe 10 months ago

  • Status changed from Merge Pending to Test

Branch 10380a was merged to trunk rev. 16203 and archived.

Also available in: Atom PDF