Closed stefandesu closed 2 weeks ago
How about deprecating direction=both
and asking clients to do two requests instead? The parameter makes implementations of mapping API more complex than needed.
I lean slightly towards just implementing it correctly (i.e. as the union of direction=forward
and direction=backward
), mostly because we don't have plans to release a new major version anytime soon, so direction=both
might be used still for a long time. We use it ourselves in Cocoda (and in coli-rich-web, if not for this incorrect behavior).
I have noticed an edge case in the behavior in GET /mappings when
direction=both
,from
, andtoScheme
(orto
andfromScheme
respectively) are given.The documentation specifies:
For the above case, I would expect the results to contain the forward case (
from
andtoScheme
as is) plus the backward case (to=from
andfromScheme=toScheme
). However,direction=both
does not always return the union of theforward
andbackward
cases. For example:returns 35 mappings, while
contain 2 and 0 mappings, respectively.
What is happening here is that the forward and backward cases are mixed in the query so that is something like this:
(
from
is SDNB 100 ORto
is SDNB 100) AND (toScheme
is BK ORtoScheme
is SDNB ORfromScheme
is BK ORfromScheme
is SDNB)The 33 unwanted mappings satisfy the conditions
from
is SDNB 100 ANDfromScheme
is SDNB, which is something I would not have expected given the query.Of course, this is a weird example, giving the
from
's vocabulary intoScheme
, but it is an actual use case I have where I now had to implement a workaround (two separate requests for forward and backward).However, I'm not 100% sure that the behavior is actually incorrect. It is just not what I would have expected or how I'd interpret our documentation. @nichtich any thoughts?