With standard CouchDB view indexes, I have flexibility and introspection into staleness vs. freshness. How do I get the analogous functionality for Cloudant's dbcopy
feature?
stale=ok
stale=update_after
stale=false
)I can compare the DB's update_seq
with the design doc's update_seq
, which can be obtained with update_seq=true
in a view query or from GET /db/_design/foo/_info
.
This is slightly clouded by BigCouch's DB partitioning and multiple servers. E.g. update_seq
is a composite and should be only compared within a tolerance range; stale=false
might choose a different shard than stale=ok
which might be more or less up to date; although there isn't a way to get the update_seq
for all nodes (or for the specific node(s) that would be chosen by stale=false
queries) it can be cheated by quickly issuing multiple /db/_design/foo/_info
queries. It would be nice to have additional shard/partition introspection here, but the above still works for my purposes.
dbcopy
dbcopy
has roughly the same "eventual consistency" characteristics. Querying the docs in chained DB is roughly analogous to querying the origin view with group=true&stale=ok
. Which is fine, most of the time. But the documentation doesn't give any pointers on the following:
dbcopy
state? E.g. Does the DB consider itself up to date or are view changes waiting their turn in the IOQ? If it's not up to date, roughly how stale is it?dbcopy
(as in stale=update_after
or stale=false
). E.g. I want something along the lines of POST /origin_db/_design/foo/_view/bar/_dbcopy
that will forcibly push the reduced results to the dbcopy
DB immediately (optionally updating the origin view first).dbcopy
mechanism or the dbcopy
mechanism misses a few documents), can this be detected? How can it be corrected? Is there a dbcopy
"reset button"?How can I query the current dbcopy state? E.g. Does the DB consider itself up to date or are view changes waiting their turn in the IOQ? If it's not up to date, roughly how stale is it?
We are looking into a better method, but at the moment the only way to get the dbcopy's current state is to compare the records in the view to the documents in the target database.
Is there a dbcopy "reset button"?
You can re-trigger the dbcopy by forcing a rebuild of the source view. This can be done by updating the design doc so that the view signature changes - e.g. adding whitespace or comments to an existing view. This is somewhat inelegant but would result in the dbcopy being re-run.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With