4 ms·
Beyond the meta of it being old/mature and thus not continually piercing the tech newsspace with releases etc. Querying in a more ad-hoc way (vs. building inde
by tehbeard 5y ago
Beyond the meta of it being old/mature and thus not continually piercing the tech newsspace with releases etc.
Querying in a more ad-hoc way (vs. building indexes ahead of time and querying by key, etc) is a bit janky / not 1st class (I think mango addresses this but not entirely sure).
The runtime being erlang? It certainly seemed to be the cause of some issues when I tried to run it in WSL, or atleast my lack of knowledge with erlang made diagnosing it more trouble.
The JS query server engine is/was fairly old (I think it might have jumped to a more recent version of Spidermonkey at some point), and hooked up in a way that, while more modular, limits the performance (documents have to be serialized to/from the engine in another process, rather than just natively passed in)
The authorization model is... unique.
You can limit down to a doc/field level who can submit changes via validate_doc_update(...) in a design doc.
So allowing those with a reviewer role to only be able to edit a notes field on a document, while the user in the author field has full access to the other fields is possible.
But read access is at the database level, as in you can either read the db, or not.
The way around this for having "private" storage is enabling a feature to make a db per user automatically and assign them rights, but this is more complicated to manage client side (two dbs to talk to) and replication even more of a nightmare if stuff needs to be shareable instead of just private.
- janl 5y agoGood observations, let me add the current state to that: > Querying in a more ad-hoc way (vs. building indexes ahead of time and querying by key, etc) is a bit janky / not 1st class (I think mango addresses this but not entirely sure). Mango does address this. > The JS query server engine is/was fairly old On the one hand, running an old JS engine isn’t big trouble for CouchDB, especially with transpiration tools available, but we now support modern SpiderMonkey up to version 91. The main benefit for CouchDB users is modern JS syntax being available. > The authorization model is... unique. per-doc-auth is in the works, no ETA, and the first iteration is going to be limited, but it’ll address the main issues for db-per-user users.