Problem when using type DOUBLE in SOAP

[Silvano Girardi Jr-2]

Gentlemen,
there is a critical issue (at least for me) when dealing with double values using SOAP.

Example: when returning 3210.8765, you get: 3211.

I reported it as a bug: http://pecl.php.net/bugs/bug.php?id=14155

FYI, when I try with REST-RPC or not using SCA at all (with SoapServer), it works fine: returns the same double value.

I appreciate if someone could take a look on this asap.

Thanks,
Silvano Girardi Jr.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters-3]

Hi Silvano,
Indeed, this is not good. I picked up the sample from the defect that
you raised.

I added a couple of trigger_errors to Bindings/soap/Wrapper.php to
look at the return values.

If I show the return value before we mess with it, it looks fine:
[Tue Jun 17 13:45:20 2008] [error] [client 127.0.0.1] PHP Notice:
3210.8765 in C:\\php\\PEAR\\SCA\\Bindings\\soap\\Wrapper.php on
 line 99

but if I look at the $response_object, which is an SDO and print that
out, it has lost precision
[Tue Jun 17 13:45:20 2008] [error] [client 127.0.0.1] PHP Notice:
object(SDO_DataObject)#11 (1) {getDoubleReturn=>"3.211e+003"} i
n C:\\php\\PEAR\\SCA\\Bindings\\soap\\Wrapper.php on line 100

So, this is something to do with assigning the value into an SDO. I
will send a note to Caroline (although of course she will see this)
and see if she knows what might have happened here.

Matthew

On 17 Jun, 00:59, "Silvano Girardi Jr" <silvan...@...> wrote:

> Gentlemen,
> there is a critical issue (at least for me) when dealing with double values
> using SOAP.
>
> Example: when returning 3210.8765, you get: 3211.
>
> I reported it as a bug:http://pecl.php.net/bugs/bug.php?id=14155
>
> FYI, when I try with REST-RPC or not using SCA at all (with SoapServer), it
> works fine: returns the same double value.
>
> I appreciate if someone could take a look on this asap.
>
> Thanks,
> Silvano Girardi Jr.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters-3]

Ouch, I have just seen that I made an error. It is the use of
trigger_error on its own that is losing precision when I print the
SDO.

If I use trigger_error(print_r($response_object, true)) then I see
that the precision is still there in the SDO:
[Wed Jun 18 16:20:39 2008] [error] [client 127.0.0.1] PHP Notice:
SDO_DataObjectImpl Object\n(\n    [getDoubleReturn] => 3210.8765\n)\n
in C:\\php\\PEAR\\SCA\\Bindings\\soap\\Wrapper.php on line 97

I need to look further....

On Jun 17, 1:52 pm, Matthew Peters <matthew.f.pet...@...>
wrote:

> Hi Silvano,
> Indeed, this is not good. I picked up the sample from the defect that
> you raised.
>
> I added a couple of trigger_errors to Bindings/soap/Wrapper.php to
> look at the return values.
>
> If I show the return value before we mess with it, it looks fine:
> [Tue Jun 17 13:45:20 2008] [error] [client 127.0.0.1] PHP Notice:
> 3210.8765 in C:\\php\\PEAR\\SCA\\Bindings\\soap\\Wrapper.php on
>  line 99
>
> but if I look at the $response_object, which is an SDO and print that
> out, it has lost precision
> [Tue Jun 17 13:45:20 2008] [error] [client 127.0.0.1] PHP Notice:
> object(SDO_DataObject)#11 (1) {getDoubleReturn=>"3.211e+003"} i
> n C:\\php\\PEAR\\SCA\\Bindings\\soap\\Wrapper.php on line 100
>
> So, this is something to do with assigning the value into an SDO. I
> will send a note to Caroline (although of course she will see this)
> and see if she knows what might have happened here.
>
> Matthew
>
> On 17 Jun, 00:59, "Silvano Girardi Jr" <silvan...@...> wrote:
>
> > Gentlemen,
> > there is a critical issue (at least for me) when dealing with double values
> > using SOAP.
>
> > Example: when returning 3210.8765, you get: 3211.
>
> > I reported it as a bug:http://pecl.php.net/bugs/bug.php?id=14155
>
> > FYI, when I try with REST-RPC or not using SCA at all (with SoapServer), it
> > works fine: returns the same double value.
>
> > I appreciate if someone could take a look on this asap.
>
> > Thanks,
> > Silvano Girardi Jr.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters-3]

OK, 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;
?>


this gives:


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>

On Jun 18, 4:23 pm, Matthew Peters <matthew.f.pet...@...>
wrote:
> Ouch, I have just seen that I made an error. It is the use of ...

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[monxton]

Matthew Peters wrote:

> OK, 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;
> ?>
>
>
> this gives:
>
>
> 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.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Silvano Girardi Jr-2]

On Wed, Jun 18, 2008 at 9:05 PM, Caroline Maynard <cem@...> wrote:

Matthew Peters wrote:
> OK, 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;
> ?>
>
>
> this gives:
>
>
> 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:

<*embarrassed*>
Sorry Caroline, I will make sure I pay attention to that next time :)

And thanks a lot Caroline and Matthew!
 

  $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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters-3]

Hi Caroline, thanks for a very authoritative answer, as always. The
one we are going to need to fix, of course, is the Tuscany behaviour,
and what it does on $xmldas->saveString($xdoc), since that is what we
use to generate the XML for the soap response ... unless we do some
horrid fix up of the generated xml afterwards. Can you work out what
the Tuscany change needs to be?

Matthew

On Jun 19, 2:33 am, "Silvano Girardi Jr" <silvan...@...> wrote:
> On Wed, Jun 18, 2008 at 9:05 PM, Caroline Maynard <c...@...> wrote:
>

> > 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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters-3]

Hi Silvano, just to say that I bumped into Caroline who said she is
going to take a look at it and see what it will take to get the right
behaviour during xml generation.

Matthew

On Jun 19, 10:40 am, Matthew Peters <matthew.f.pet...@...>
wrote:

> Hi Caroline, thanks for a very authoritative answer, as always. The
> one we are going to need to fix, of course, is the Tuscany behaviour,
> and what it does on $xmldas->saveString($xdoc), since that is what we
> use to generate the XML for the soap response ... unless we do some
> horrid fix up of the generated xml afterwards. Can you work out what
> the Tuscany change needs to be?
>
> Matthew
>
> On Jun 19, 2:33 am, "Silvano Girardi Jr" <silvan...@...> wrote:
>
> > On Wed, Jun 18, 2008 at 9:05 PM, Caroline Maynard <c...@...> wrote:
>
> > > 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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Silvano Girardi Jr-2]

Ok! We will be using string until there is no fix for it.

Thank you!
Silvano

On Tue, Jun 24, 2008 at 6:27 AM, Matthew Peters <matthew.f.peters@...> wrote:

Hi Silvano, just to say that I bumped into Caroline who said she is
going to take a look at it and see what it will take to get the right
behaviour during xml generation.

Matthew

On Jun 19, 10:40 am, Matthew Peters <matthew.f.pet...@...>
wrote:

> Hi Caroline, thanks for a very authoritative answer, as always. The
> one we are going to need to fix, of course, is the Tuscany behaviour,
> and what it does on $xmldas->saveString($xdoc), since that is what we
> use to generate the XML for the soap response ... unless we do some
> horrid fix up of the generated xml afterwards. Can you work out what
> the Tuscany change needs to be?
>
> Matthew
>
> On Jun 19, 2:33 am, "Silvano Girardi Jr" <silvan...@...> wrote:
>
> > On Wed, Jun 18, 2008 at 9:05 PM, Caroline Maynard <c...@...> wrote:
>
> > > 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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[monxton]

Matthew Peters wrote:
> Hi Caroline, thanks for a very authoritative answer, as always. The
> one we are going to need to fix, of course, is the Tuscany behaviour,
> and what it does on $xmldas->saveString($xdoc), since that is what we
> use to generate the XML for the soap response ... unless we do some
> horrid fix up of the generated xml afterwards. Can you work out what
> the Tuscany change needs to be?

I've raised a Tuscany defect:
http://issues.apache.org/jira/browse/TUSCANY-2439 and offered them a
patch. I'll keep you posted.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[monxton]

Caroline Maynard wrote:

> I've raised a Tuscany defect:
> http://issues.apache.org/jira/browse/TUSCANY-2439 and offered them a
> patch. I'll keep you posted.

Tuscany developers have committed my patch, and I've also made a change
to the SDO extension so that Tuscany will honour the precision value
defined in php (http://php.net/manual/en/ini.core.php#ini.precision).
Note that the extension won't re-read this setting if you change it with
ini_set('precision') - it must be in effect before the script starts to run.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---