In invenio-vocabularies we have read, read_all and read_many. When searching for generic vocabularies, we give two parameters vocabulary type and ids (e.g. resourcetype and publication). In the case that publication does not exist the result would be:
read --> NoResultFound (404)
read_many and read_all --> empty search result (i.e. hits: [])
However, all three methods assume that the vocabulary type (e.g. resourcetype) exists in db (we are querying .one() with no try/except). Then, it make the search page with a 404 because a NoResultFound is risen. It leads me to:
read --> NoResultFound (404) . This is still correct, however, should we expose in the error if what does exist is the type instead of the actual id?
read_many and read_all --> Here is the important part:
Imitating the empty search result (i.e. hits: []) would be the desired output for internal usage (e.g. facets). However, it is semantically incorrect, since it's not empty but rather doesn't exist.
404, would need to handle this internally when labelling vocabularies <-- I'm leaning towards this solution, but would mean silent failure
In invenio-vocabularies we have
read
,read_all
andread_many
. When searching for generic vocabularies, we give two parameters vocabularytype
andids
(e.g. resourcetype and publication). In the case that publication does not exist the result would be:read
-->NoResultFound
(404)read_many
andread_all
--> empty search result (i.e.hits: []
)However, all three methods assume that the vocabulary type (e.g. resourcetype) exists in db (we are querying
.one()
with no try/except). Then, it make the search page with a 404 because aNoResultFound
is risen. It leads me to:read
-->NoResultFound
(404) . This is still correct, however, should we expose in the error if what does exist is the type instead of the actual id?read_many
andread_all
--> Here is the important part:hits: []
) would be the desired output for internal usage (e.g. facets). However, it is semantically incorrect, since it's not empty but rather doesn't exist.