q parameter does not work on members end-point

[tloubrieu-jpl]

🐛 Describe the bug

I am not sure if that is intended to work in the first place, but in case yes,

the following request

curl --get 'http://pds.nasa.gov/api/search-en-gamma/1.1/classes/collections/urn:nasa:pds:gbo.pluto-charon.mutual-events:data::1.0/members' --data-urlencode 'q=pds:External_Reference.pds:reference_text eq "YOUNG1992"' -H Accept:application/json -L | json_pp

Does not filter the results. We get the same response with request:

curl --get 'http://pds.nasa.gov/api/search-en-gamma/1.1/classes/collections/urn:nasa:pds:gbo.pluto-charon.mutual-events:data::1.0/members' -H Accept:application/json -L | json_pp

🕵️ Expected behavior

The filter should (To Be confirmed) apply to the members of the collection requested.

📚 Version of Software Used

1.1

[tloubrieu-jpl]

For this ticket, focus on /products/{id}/members... since the /classes/{class}/{id}/memebers... are now deprecated.

[alexdunnjpl]

@jordanpadams can you confirm that this behaviour is a requirement? (Only asking since Thomas mentioned that it's unclear)

[jordanpadams]

@alexdunnjpl I think we want to support q= across all endpoints (why wouldn't we?), but if there are other higher priority bugs out there, this isn't totally critical.

[alexdunnjpl]

@jordanpadams after digging through the relevant code and running it by @al-niessner, the short answer to "why wouldn't we" is "because the raw query q= is intended as a way to expose a low-level interface for custom querying, and the architecture isn't designed to support combination in the necessary fashion".

An alternative approach to provide similar functionality is to extend the query language to include operators for references (ex. /products?q="grandchild-of urn:bundle::1.0 and instrument = mars_hires_camera)

[jordanpadams]

@al-niessner @alexdunnjpl copy. we can close this as wontfix, but I will create a new requirement to support more complex queries combining both aggregation searches with metadata searches.