Hi Chris,
On 05.01.10 19:32, Chris Anderson wrote:
If you store the full path (A, B) on the Cs as well, then you can collate like:
A,
A, B
A, B, C
A, B2
A, B2, C
A, B2, C2
etc.
If you are paginating through large directories, then you'll want to
store the parent metadata in client state, so you don't have to reload
it for each page.
I don't see how that can help when a user requests a C without knowing
that it is a C and has a parent B and A. I still need to either allow
access or deny it. I don't see how something like this is possible with
CouchDB out of the box, as I don't have the ability to make another request.
Without knowing more about the actual requirements, I can't argue this
point, but I've seen my share of cases that were simplified greatly by
moving to a key-value model. For instance, S3 has a per-bucket
security model, which is very similar to CouchDB's planned
per-database read control model.
If you use a database-per-user (or group), quota calculations will
become much easier (and more realistic, as they account for actual
disk space used, not just total stored file size). You also get a
bunch of other simplifications (like the ability to replicate data
independently, also you don't have to worry so much about fine-grained
access control.) CouchDB can handle millions of databases on a single
node.
I can not use a database per user or group, as both are completely
dynamic (e.g. a user may gain or loose access on some documents any
time). But I could use a separate database for any A (and storing all
B's and C's within it) - would that help? I can't see how currently...
regards,
Joscha
