Closed bakura10 closed 7 years ago
Thank you very much for your contribution. You fix looks good and you even add tests. Thumbs up!
Thanks a lot ! It seems there is a lot of missing coverage with serializing query attributes, as I'm maintaining some big descriptors and starting to upgrade them, it's possible that I encounter other regressions. I'll make sure to fix them as they arise :).
In the mean time would it be possible to tag this ? :)
Hey !
Apparently I've messed and I've made the PR against the "develop" branch. Should I re-do the PR to master so that this can be tagged?
Nope. I changed it to develop intentionally because master only should contain tagged versions. I follow git flow here: http://danielkummer.github.io/git-flow-cheatsheet/
@bakura10 Just tagged version 1.0.1. Hope it works for now. You are very welcome to open issues and/or PRs. I will try to get everything fixed as soon as possible.
Addresses #128
This PR is likely a BC of 1, but as the behaviour of 1.0.0 is wrong and completely different from previous version, I think it's more a bug fix rather than a BC. Also there was no test to verify this behaviour.
Currently, the Guzzle Service serializes incorrectly any query params that are array or object.
For instance, considering this operation's param:
Specifying this parameter: $client->myOperation(['foo' => [1, 2]]) would serialize this query parameter : foo=1&foo=2, which is completely different from the older behaviour and, from my understanding, incorrect.
Similarily, when specifying an object type, this: $client->myOperation(['foo' => ['bar' => 'baz']]) would serialize this query "foo=baz" (hence completely loosing the context of bar).
After this PR, first operation would be serialized 'foo[0]=1&foo[1]=2' and second operation would be serialized 'foo[bar]=baz'.
Thanks a lot!