php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #36226 Inconsistent handling when passing potential arrays.
Submitted: 2006-01-31 13:24 UTC Modified: 2007-03-20 07:52 UTC
From: say_ten at multiplay dot co dot uk Assigned: dmitry (profile)
Status: Closed Package: SOAP related
PHP Version: 5.1.2 OS: FreeBSD 6.0-p4
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: say_ten at multiplay dot co dot uk
New email:
PHP Version: OS:

 

 [2006-01-31 13:24 UTC] say_ten at multiplay dot co dot uk
Description:
------------
When using the following WSDL reponse the server is allowed to return 0 to many recipes.

<xsd:complexType name="getRecipesResponse_t">
    <xsd:sequence>
        <xsd:element name="recipes" type="types:Recipe" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
</xsd:complexType>

The code returned from the function would be of the type:

array( array( "id" => 3, "recipe" => cake, "description" => "desc" ) );

If their is only 1 recipe the client returns a standard object of the recipe.  If there's more than one, the client returns an array of recipes.  This inconsitency results in code to detect and wrap the std class into an array for compatibility with the following code, foreach() for example.  This is also true when passing arrays of arrays to the SOAP server.

Expected result:
----------------
I would expect the single element arrays passed in to remain single element arrays at the other end.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-01-31 15:45 UTC] tony2001@php.net
Assigned to the maintainer.
 [2006-02-02 12:42 UTC] dmitry@php.net
This is not a bug but feature.
I stayed the default behavior unchanged, but added ability to create arrays even if only one element exists.
To create arrays with single element, you should use special option in SoapServer/SoapClient constructor.

$x = new SoapClient($wsdl, array('features' => SOAP_SINGLE_ELEMENT_ARRAYS));

Fixed in CVS HEAD and PHP_5_1.
 [2007-02-08 15:32 UTC] lsmith@php.net
Enabling this feature seems to result in giving me an array(null) if I have a nill'ed sequence. Not sure if this is why you originally introduced the feature of not returning single element sequences as array's, but I was hoping to get an empty array in the above case.
 [2007-02-15 15:47 UTC] dmitry@php.net
Could you please provide a working example with expected output. I cannot imagine the situation when ext/soap will return array(null) for unexisting XML elements.
 [2007-02-23 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2007-03-18 10:15 UTC] lsmith@php.net
Ah ok .. I finally had the genius idea of searching the existing test cases for one that covers my issues. Since I am a phpt n00b, I ripped the code instead of simply updating the test case. The code should be similar enough for you to recognize from the test case for Bug #36226.&#13;&#10;&#13;&#10;http://pooteeweet.org/public/SOAP_SINGLE_ELEMENT_ARRAYS.phps&#13;&#10;&#13;&#10;I did a minor change to the wsdl to allow nillable for the sequence.&#13;&#10;&#13;&#10;http://pooteeweet.org/public/bug35142.wsdl&#13;&#10;&#13;&#10;Would be nice to have that one fixed for php 5.2.2.&#13;&#10;&#13;&#10;So the issue is that I end up with an array(null) for logOnEvent instead of simply null. 
 [2007-03-20 07:52 UTC] dmitry@php.net
Fixed in CVS HEAD and PHP_5_2.
 [2012-04-16 09:54 UTC] a at b dot com
@dmitry: Can you explain why you consider inconsistent behaviour a feature?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 12:01:29 2024 UTC