10 query available beamlines #13
Conversation
callumforrester
force-pushed
the
10-query-available-beamlines
branch
from
b7348be to
165b8f8
Compare
callumforrester
force-pushed
the
10-query-available-beamlines
branch
4 times, most recently
from
9d0fc79 to
05d85ea
Compare
There was a problem hiding this comment.
I'm still not sure of the use case for this beyond curiosity so this may answer itself.
Instead of beamline_filter being a single string that returns a list of one configuration, would the more graphql-ish approach to pass in a list of names and it returns a list of (possibly null) configurations so that mapping from beamline name to configuration is easier. Not passing the filter list would be the same as it currently is. Passing an empty list would be pointless but would return an empty list.
src/graphql.rs
Outdated
| match beamline_filter { | ||
| Some(filter) => { | ||
| trace!("Getting configs matching {filter:?}"); | ||
| let singleton = db.current_configuration(&filter).await?; |
There was a problem hiding this comment.
This currently returns an error if the beamline has no configuration. Given that the query now returns a list, would it make more sense to return an empty list?
There was a problem hiding this comment.
I've done this but I'm on the fence about it. The DB service returns an error if it can't find the beamline because the other queries like to fail when there's no configuration. It now seems a bit inconsistent. This query basically returns an Option and everything else returns a Result.
Expand configuration query to be able to return multiple configurations. Change name to configurations. Make beamline parameter optional (and rename to beamlineFilter). When a filter is provided, only details for that beamline are returned, otherwise all beamline configurations are returned. Also add a test for the multi-configuration DB query and update the example query in the README.
Expose the name of a configuration (which matches the name of the beamline) in the GraphQL API. Now that we have a query that returns a list of configurations it is useful to have a field that can differentiate between them.
Return an empty vector from the configurations query if a beamlineFilter is provided but does not match a beamline, previously the API returned an error in this case.
callumforrester
force-pushed
the
10-query-available-beamlines
branch
from
05d85ea to
cf8edda
Compare
|
Setting this back to a draft for now, some of the tests might still be relevant but most of this change has been moved to #72 |
Fixes #10
Expand configuration query to be able to return multiple configurations. Change name to configurations. Make beamline parameter optional (and rename to beamlineFilter). When a filter is provided, only details for that beamline are returned, otherwise all beamline configurations are returned.
Expose the name of a configuration (which typically matches the name the beamline) in the GraphQL API. Now that we have a query that a list of configurations it is useful to have a field that differentiate between them.