New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing array compared to suds-jurko #67
Comments
Hi @tpow thanks for opening an issue and for providing a test case, that's fantastic.
To clarify here,
where is the next level marked as required? Does the WSDL itself leave these objects as optional, but the server interpretation require them?
Would something like Since this is less convenient and a pain to convert codebases if you're trying to convert to suds-community, one workaround is here: BingAds/BingAds-Python-SDK@8d1a515#diff-84a7c57706647cffbba7321972ce82a9aa06e7d49b8c32b4d7a34417ffba9e45R13, provide a custom Builder class to Since this has come up a few times, I could see a few options going forward:
What do you think? |
@phillbaker Thank you for the helpful feedback and suggestions. It is possible that this API is incorrectly constructed, but as we say at work "the real world is messy" and we need to deal with it. When I said that Although as you noticed, these are "optional" with minOccurs = "0"
However, the elements they reference are not (and also are complex types). For example, the
Because of this, I was thinking I'm not sure if this
but then I would still need to create the ChargeInMsg and do the setup. It would be a little inconvenient to have to do both. That was my understanding of why What are your thoughts? |
Update: we tested the API with additional code: if req.Charges is None:
req.Charges = client.factory.create("ns1:ArrayOfChargeInMsg") This generated a request like this:
This worked fine, so the API is handling the "optional" values as the schema indicates. I still think it would be convenient (and assist with the transition from suds-jurko) to construct the empty lists so we don't need to build the Thanks! |
I pushed a change which tries to implement the suggestion on https://github.com/suds-community/suds/tree/bugfix/complex-sequence, however, it causes other tests to fail. For now, I've implemented the alternative approach involving subclassing, see 366f7f1. |
Thanks for working on this @phillbaker. I believe the subclassing approach may be all that is needed and is easy enough. Is it worth adding it to the readme/docs? One point of clarification: I believe the description in 366f7f1 is inaccurate. This behavior was in the latest released version of suds-jurko which is why I reported it. I believe suds-community implemented the new behavior before any official release, but suds-jurko definitely had the old behavior in the released versions. |
366f7f1 includes an update to the readme, https://github.com/suds-community/suds#initializing-optional-arrays-with-lists
Hm, the last released version of suds-jurko is 0.6 (https://pypi.org/project/suds-jurko/#history), corresponding to this tag: https://github.com/suds-community/suds/releases/tag/release-0.6, released in 2014. Issue #14 identifies this commit as introducing the change: b6d1d09, from 2015. So it doesn't seem like it was in suds-jurko, but it was released in suds-community in v0.7.0 (the first suds-community release) and then the change in #15 was released in suds-community 0.8.0. So suds-community definitely changed. Thanks for opening the issue and providing helpful feedback! I'm going to close this issue for now, if folks can make bugfix/complex-sequence work, would be happy to review a PR that implements that behavior as well. |
We recently evaluated switching to suds-community from suds-jurko and found a compatibility problem. Elements that were previous populated with empty lists are now set to None. Here's the comparison:
suds-community gives this:
Versus suds-jurko:
I've dug in to the problem and narrowed it down to the change in behavior due to #14, #15, and #16. Reverting the changed line (as in
setattr(data, type.name, value) # if not type.optional() or type.multi_occurrence() else None)
) in builder.py fixes the problem for us, but think I understand why the change was made in the first place so suspect that removing all of it is not the right solution.My guess is that
multi_occurrence()
needs to look recursively into the nesting before failing. In our case the top level is optional, but the next is not.It is also possible that we aren't using suds correctly or misunderstand the structure somehow, but I can say that the code works with sud-jurko and not with suds-community.
Although the API we are calling is not public and is controlled by a vendor, I have built the following test that demonstrates the problem. If dropped into the test suite, it should run and fail. Note that this is a pruned down and somewhat modified version of the vendor's schema and almost certainly could be simplified more. Sorry that it is a bit noisy.
It looks like incorporating parts of this into the test suite, perhaps as an expansion to the changes made for the #16 pull request would be beneficial.
We would appreciate any clarification if we are misusing suds somehow and/or confirmation that this is a bug.
Thanks! Tim
The text was updated successfully, but these errors were encountered: