It has come up a few times that we needed the add-exists handler to produce a query clause that checks multiple values. Most notably if a resource is nested like /client/:client-id/resource/:id. Using (add-exists :id) allows an :id being returned that isn't associated with :client-id. The connections service uses two different ways to get around this. It has an input-transform that assoc's the :client-id into the key sweet-lib pulls from to generate the query and it also uses the :defaults sweet-lib key to assoc in a namespace to restrict queries for (/clients/:client-id/:namespace/connections). I think neither of these approaches are optimal and instead the add-exists handler should allow a variable number of arguments.
It has come up a few times that we needed the
add-exists
handler to produce a query clause that checks multiple values. Most notably if a resource is nested like/client/:client-id/resource/:id
. Using(add-exists :id)
allows an:id
being returned that isn't associated with:client-id
. The connections service uses two different ways to get around this. It has aninput-transform
that assoc's the:client-id
into the key sweet-lib pulls from to generate the query and it also uses the:defaults
sweet-lib key to assoc in a namespace to restrict queries for (/clients/:client-id/:namespace/connections
). I think neither of these approaches are optimal and instead theadd-exists
handler should allow a variable number of arguments.