I have a server, with a couchdb database that contains information my application needs. It contains a couple megabytes of stuff, a few documents which change on a day-to-day basis (adding latest news, deleting old documents, updating a few).
The application syncs with the servers database when it can (to have this information available offline).
However, this information is global to every user of my application -- so by necessity needs to be restricted to strictly read-only access. However, I read that couchdb requires write access to the source in order to replicate effectively (in order to checkpoint).
What are the performance implications? And are there any ways around this?
You can restrict write access by writing a validate_doc_update()
function in a _design document. You can find the details in the official CouchDB documentation.
For example, this function would restrict write operations to admins only:
function(newDoc, oldDoc, userCtx, secObj) {
// allow modifications by admins only.
if ((userCtx.roles.indexOf('_admin') !== -1)) {
return;
}
throw({forbidden: 'You are not allowed to edit public documents.'});
}
Put this into a _design/readonly
document (or whatever name you'd like for the design document), and name the function validate_doc_update
.
Each design doc can only have one validate_doc_update function, but you can of course define several design documents. Whenever a write operation is tried by anyone, the document is sent to all those validation functions in sequence. If any function throws an error, the update is rejected.
So be careful not to replicate this design document to databases which normal users should be able to write to!
As far as I know, regular replications will still work, because validation functions are not executed against the replication checkpoint documents (they have the special /_local/ prefix). But you should definitively try this out to be sure.
The validate functions are executed every time a document write occurs, even for admin writes, also for replications. Depending on your application, you might consider some special strategies for replications to improve performance.
The setup you described shouldn't pose a problem, though: Users are not allowed to write, so it's ok if they experience slow replications to your public database. And if your public database is updated only very seldomly, there shouldn't be any performance problems either.
Hope I could help!
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