phillbaker
commented
5 years ago Hi @guifran001 thanks for opening an issue, very interesting!
I've also noticed the unfortunate side effect that instantiating an object with optional attributes instantiates that object recursively.
To quote from the commit message:
Before, passing an empty suds object as an optional parameter value was treated the same as not passing that parameter's value or passing it None - the value would not get marshalled into the constructed SOAP request at all.
Now, user can still not have the value marshalled by passing nothing or None, but passing an empty object will get marshalled as an actual SOAP request XML element.
This seems correct as passing an empty object and not passing an object are two distinct use-cases and there are web-services out there (e.g.
https://ads.google.com/apis/ads/publisher/v201502/LineItemService?wsdl) that do differentiate between the two.
I don't think simply reverting the change is the right course, as the fix does address a valid usecase: passing an empty object. But perhaps we can separate the instantiation from the serialization? For example, instead of:
# suds-community now
client.factory.create("SomeObject")
(SomeObject){
Foo = 123456
Required =
(Foo){
Bar = None
}
Optional =
(Foo){
Bar = None
}
_MessageId = "1a88625d-57d4-4c4e-b3e4-7c5caa7bfe5f"
}we instead do (ie forcing the explicit creation of empty objects):
# suds-community proposed change
o = client.factory.create("SomeObject")
o
(SomeObject){
Foo = 123456
Required =
(Foo){
Bar = "baz"
}
Optional = None
_MessageId = "1a88625d-57d4-4c4e-b3e4-7c5caa7bfe5f"
}
o.Optional = client.factory.create("Foo")
o.Optional
(Foo){
Bar = None
}I'm a little puzzled that the Appender in the commit is used in the creation of objects as well. Any chance you can dig into the factory.create method to see how it ends up calling the Appender?
guifran001
The following commit https://github.com/suds-community/suds/commit/b6d1d0979e1847a6b8f267be1888892e9327c2a6 introduced a behavior change that breaks code that was using suds-jurko 0.6.
Since, this code was never released, I wonder if the commit could be reverted. Originally, it was to fix this problem: https://bitbucket.org/jurko/suds/issues/81
The original behavior was (suds-jurko 0.6): When creating a sudsojbect.Object this way: client.factory.create("myObjectr"), the instanciated object has all its optional attributes were set to None and not added into the payload when calling a service with this object as argument.
The new behavior is (suds-community): When creating a sudsojbect.Object this way: client.factory.create("myObject"), the instantiated object has all its optional attributes set. When calling a service with with this object as argument will result with having those optional attributes in the payload as
I don't think the new behavior is correct, because if one updates a SOAP service to add an optional attribute to an object, it is absurd that all the clients using suds will start to add it by default and therefore change the expected behavior (the absence of an optional attribute is different than the presence of an empty attribute (for the server we are using at least)).
I've not been able to think of a solution for the original issue though, but it should not be fixed like that.
Can the commit be reverted ?