Given that there are different kinds of searches, ones that are basic sets of variables and ones that are more complex JSON queries, the MetaCPAN::API::* methods should be able to adapt to both. To best solve this on the API.pm end, I added the extra logic to _build_extra_params to auto-convert deep objects to GET-encoded JSON with the source parameter.
Without the change, release passes it to fetch, fetch passes it to _build_extra_params, and _build_extra_params just dumbly encodes references as HASH(whatever) ref memory strings.
This is sort of a workaround, as the real solution would be some sort of fetch_or_post method that just does the right thing according to extra_params, if it's deep, and if it's nearing its 2000 character or so limit for query strings. However, having this logic here is still good as a DWIM measure, even if I did patch for that. (Which I probably will, when it's not 11:50PM :)
Given that there are different kinds of searches, ones that are basic sets of variables and ones that are more complex JSON queries, the MetaCPAN::API::* methods should be able to adapt to both. To best solve this on the API.pm end, I added the extra logic to _build_extra_params to auto-convert deep objects to GET-encoded JSON with the source parameter.
This makes queries like this possible:
Without the change, release passes it to fetch, fetch passes it to _build_extra_params, and _build_extra_params just dumbly encodes references as HASH(whatever) ref memory strings.
This is sort of a workaround, as the real solution would be some sort of fetch_or_post method that just does the right thing according to extra_params, if it's deep, and if it's nearing its 2000 character or so limit for query strings. However, having this logic here is still good as a DWIM measure, even if I did patch for that. (Which I probably will, when it's not 11:50PM :)