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
/v1/module handles fields parameter in a way that produces single-value arrays #580
Comments
I know the 'utility' of flattening arrays is nice, but if it leads to our code having lots of these we should seriously consider just keeping them as arrays all the time |
s/keeping them/keeping results/ |
Well, it's a huge PITA for consumers which otherwise would just be able to change endpoints and be done with it. |
For this particular endpoint, we obviously take pains to collapse single-valued arrays, but miss the case when the |
We can also refactor the controller/model code such that there's only a few places where the output gets filtered through our munger. |
…ic fields We claim in our docs¹ that our convenience endpoints revert the newer Elasticsearch behaviour of wrapping single values in arrays. This makes that so in more places, specifically the places where the client has requested a limited subset of fields. While this may seem like a pain for us and lead to uglier code, think about it this way: either we do it for our API one time, or every client that runs into the issue has to do it themselves many times over. A better solution may exist which centralizes application of single_valued_arrayref_to_scalar(), but this works for now. See also GH#580 for an example case.² ¹ https://github.com/metacpan/metacpan-examples/blob/master/README.md#upgrading-from-v0 ² #580
…ic fields We claim in our docs¹ that our convenience endpoints revert the newer Elasticsearch behaviour of wrapping single values in arrays. This makes that so in more places, specifically the places where the client has requested a limited subset of fields. While this may seem like a pain for us and lead to uglier code, think about it this way: either we do it for our API one time, or every client that runs into the issue has to do it themselves many times over. A better solution may exist which centralizes application of single_valued_arrayref_to_scalar(), but this works for now. See also GH#580 for an example case.² This reverts a small change to tests which was made to accommodate the new ES behaviour. ¹ https://github.com/metacpan/metacpan-examples/blob/master/README.md#upgrading-from-v0 ² #580
Fixed in #581. |
Compare:
I'll take a look at this in the next couple days if no one else does.
The text was updated successfully, but these errors were encountered: