You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It happens that most CouchDB responses follow this shape, and so mapping is unnecessary most of the time, and we already do mapping on some apis ie. retrieveDocument maps 404, createDocument maps/handles 409, 400 and 403, etc.
But I do think this adapter could do a better job of explicitly mapping per request statuses to specific HyperErrs instead of just accepting whatever is sent back from CouchDB. This way, the mapping can be tested.
This issue is meant to track that enhancement of the non-happy path. This includes:
createDatabase - should return a HyperErr if the database already exists
removeDatabase - should return a HyperErr if no database is found to remove
removeDocument - should return a HyperErr if no document is found to remove
These above have commented out tests that can be used to verify we've implemented the expectation. But there are lots of errors that could be returned from Couch
I'd consider this more of an enhancement.
A "HyperErr" is a simple object of the shape:
It happens that most CouchDB responses follow this shape, and so mapping is unnecessary most of the time, and we already do mapping on some apis ie.
retrieveDocument
maps404
,createDocument
maps/handles409
,400
and403
, etc.But I do think this adapter could do a better job of explicitly mapping per request statuses to specific HyperErrs instead of just accepting whatever is sent back from CouchDB. This way, the mapping can be tested.
This issue is meant to track that enhancement of the non-happy path. This includes:
createDatabase
- should return a HyperErr if the database already existsremoveDatabase
- should return a HyperErr if no database is found to removeremoveDocument
- should return a HyperErr if no document is found to removeThese above have commented out tests that can be used to verify we've implemented the expectation. But there are lots of errors that could be returned from Couch
Ideally, the solution is something that is reusable to handle all sorts of CouchDB errors, similar to the approach for mapping errors in the elasticsearch adapter
The text was updated successfully, but these errors were encountered: