O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na internet.
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...@gmail.com> wrote:
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...@googlemail.com>
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...@gmail.com> 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.
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.
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.
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:
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.
On Wed, Jun 18, 2008 at 9:05 PM, Caroline Maynard <c...@php.net> 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.
> 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 :)
> 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.
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...@gmail.com> wrote:
> On Wed, Jun 18, 2008 at 9:05 PM, Caroline Maynard <c...@php.net> 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.
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...@googlemail.com>
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...@gmail.com> wrote:
> > On Wed, Jun 18, 2008 at 9:05 PM, Caroline Maynard <c...@php.net> 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.
> 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...@googlemail.com> > 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...@gmail.com> wrote:
> > > On Wed, Jun 18, 2008 at 9:05 PM, Caroline Maynard <c...@php.net> > 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.
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?
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?
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.
|
