Post by Matthew PetersOK, this testcase is enough to demonstrate the problem (using
Sample.wsdl from the defect that Silvano raised). The problem is not
that the sdo does not have the precision; it's in the serialisation to
xml which treats the value like 'print' does and not 'print_r'. Still
needs further investigation.
<?php
$xmldas = SDO_DAS_XML::create('./Sample.wsdl');
$sdo = $xmldas->createDataObject('http://Sample','getDoubleResponse');
$sdo->getDoubleReturn = 1.23456789;
print_r($sdo);
print "\n";
print $sdo;
print "\n";
print "\n";
$xdoc = $xmldas->createDocument('', 'BOGUS', $sdo);
$xmlstr = $xmldas->saveString($xdoc, 0);
print $xmlstr;
?>
SDO_DataObjectImpl Object
(
[getDoubleReturn] => 1.23456789
)
object(SDO_DataObject)#3 (1) {getDoubleReturn=>"1.235e+000"}
<?xml version="1.0" encoding="UTF-8"?>
<BOGUS xsi:type="tns2:getDoubleResponse" xmlns:tns2="http://Sample"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tns2:getDoubleReturn>1.235e+000</tns2:getDoubleReturn>
</BOGUS>
I did at first stop reading this thread at its first line, which was
really not a good way to get my attention. But I have relented, and
tried running Matthew's testcase above, though substituting the first
two lines with some straight SDO using Silvano's original schema:
$xmldas = SDO_DAS_XML::create('./Samples.xsd');
$sdo = $xmldas->createDataObject('http://Samples','Sample');
I observe that there doesn't seem to be a problem with the data itself,
only with the way it is printed. The difference is that in the "good"
cases, the data (PHP Double type) is handed to the PHP engine to print,
but in the "bad" cases, it is Tuscany which is doing the conversion to a
string before PHP gets a look in.
(Note that PHP has a single type which is used for floats and doubles,
whereas Tuscany, C++ and XML treat them as different types.)
When PHP prints a double, it uses a printf format string of "%.nG",
where the precision (n) is configurable (see
http://php.net/manual/ini.core.php#ini.precision). %G says use %E
(scientific) or %f, whichever is the shorter.
When Tuscany does the same thing, it uses "%.3Le" for a double, or
"%.3e" for a float. This means that it will always use scientific
notation, with only 3 decimal places, as we have observed.
It's possible to avoid using the Tuscany conversion code by adding a
chunk more code to handle it ourselves, as we do when returning data as
values, rather than just printing it. I'll have a go at this.
I think this accounts for the behaviour of Matthew's testcase. But we're
going through similar Tuscany code when converting between SDOs and XML,
and this will really need a Tuscany change.
I did check this against the SDO 2.1 spec, and that expects doubles and
floats to be printed as [0-9]*('.'[0-9])?('E'|'e'). So I don't know
where Tuscany got its format. Certainly not from the XML schema spec:
http://www.w3.org/TR/xmlschema-2/#float.