7 ms·

Great, thanks for the helpful info! Oh, one more thing: Did you ever load multiple TouchDBs? I'm thinking the overhead per DB (not per server) should be pretty

by DeepDuh 14y ago

Great, thanks for the helpful info! Oh, one more thing: Did you ever load multiple TouchDBs? I'm thinking the overhead per DB (not per server) should be pretty small, no? Background: I'd like to build an application where I separate entities into multiple couchDBs, partly since it saves me view definition code, partly because it gives me more flexibility for per-document access permissions.

greendestiny 14y ago
Yes I have a framework that splits itself into 3 databases and has quite a lot of attachments. There isn't a big overhead as far as I can see. Does couchDB do what you need with per-document access permissions? It seems to be the biggest downside to couchdb is having to do so many workarounds for per-document access permissions.
- DeepDuh 14y ago
  That's also my conclusion. However I'm not aware of a DBMS that - is document based - can easily replicate to laptops and embedded devices - has all the security I want, e.g. encryption, per document security - has the bindings I want and/or a new binding can easily be implemented ad-hoc Given the advantages and disadvantages I'm leaning towards CouchDB and rolling my own security wrapper. IMO that's still better than going with an RDBMS and then implementing replication[1]. How do you see this? [1]edit: and also giving up the document based approach, thus not having arbitrary mapping from the get go.
  - greendestiny 14y ago
    I love couchdb for its replication, not only did I use it for a previous company I worked for and still contract with, I'm using it for my 'big idea' project. Once you have data replication you do need some kind of different approach to user/document security - after all they can take the data they have and do anything with it - so you need to treat replication as data input and validate there, like couchDB does. I think the real downsides are scaling and performance but there are options at least. Given that TouchDB is essentially couchdb mapped onto sqlite I do wonder if there are going to be good options to map couchdb replication onto postgres in future.
    - DeepDuh 14y ago
      oh, so TouchDB maps to sqlite? Does that work generally? Let's say my documents have lists of maps of tuples of lists - will it create the appropriate table structure in sqlite? The use cases I have in mind don't need the DB to scale to more than a few ten thousand users. Should be ok with a two or three replicated nodes I think, from my experience with Lotus Notes.
      - greendestiny 14y ago
        I think each document is a row and it parses it to native structures on load. I think I saw something on the dev list about that being improved - but its something to check if it matters.
    - DeepDuh 14y ago
      [edit: sorry, I replied here, because it wouldn't let me reply to your other answer first and I thought it was because we've reached some kind of maximum depth] Thanks, I see. Ok, if it's just string or binary based it will work from a correctness standpoint. I'd expect big performance problems with ad-hoc views (if they even exist here), but these shouldn't be used in production anyways. Also, I'd expect replication to take quite a bit longer because it needs to map every document with changes, so there's going to be a tradeoff between initialization time and replication time between the two approaches. I'm thinking it's going to be beneficial for larger databases to have a TouchDB 'server' somewhere, which constantly replicates with CouchDB and sends the devices a complete snapshot sqlite file for the initial setup. After that, they can talk to CouchDB directly. Otherwise it could take like half an hour to initialize a 50MB DB on a device, which is not really feasible.
      - greendestiny 14y ago
        In fact for a while you could only have adhoc views, but my knowledge is 6 months out of date. Yes definitely do that. I bundle the sqlite in the app store updates and then mount that as an external db and pull from itself - its a bit awkward but it worked. I had to write the external db stuff, but it was pretty easy.

by DeepDuh 14y ago

greendestiny 14y ago

Yes I have a framework that splits itself into 3 databases and has quite a lot of attachments. There isn't a big overhead as far as I can see. Does couchDB do what you need with per-document access permissions? It seems to be the biggest downside to couchdb is having to do so many workarounds for per-document access permissions.

DeepDuh 14y ago
That's also my conclusion. However I'm not aware of a DBMS that - is document based - can easily replicate to laptops and embedded devices - has all the security I want, e.g. encryption, per document security - has the bindings I want and/or a new binding can easily be implemented ad-hoc Given the advantages and disadvantages I'm leaning towards CouchDB and rolling my own security wrapper. IMO that's still better than going with an RDBMS and then implementing replication[1]. How do you see this? [1]edit: and also giving up the document based approach, thus not having arbitrary mapping from the get go.
- greendestiny 14y ago
  I love couchdb for its replication, not only did I use it for a previous company I worked for and still contract with, I'm using it for my 'big idea' project. Once you have data replication you do need some kind of different approach to user/document security - after all they can take the data they have and do anything with it - so you need to treat replication as data input and validate there, like couchDB does. I think the real downsides are scaling and performance but there are options at least. Given that TouchDB is essentially couchdb mapped onto sqlite I do wonder if there are going to be good options to map couchdb replication onto postgres in future.
  - DeepDuh 14y ago
    oh, so TouchDB maps to sqlite? Does that work generally? Let's say my documents have lists of maps of tuples of lists - will it create the appropriate table structure in sqlite? The use cases I have in mind don't need the DB to scale to more than a few ten thousand users. Should be ok with a two or three replicated nodes I think, from my experience with Lotus Notes.
    - greendestiny 14y ago
      I think each document is a row and it parses it to native structures on load. I think I saw something on the dev list about that being improved - but its something to check if it matters.
  - DeepDuh 14y ago
    [edit: sorry, I replied here, because it wouldn't let me reply to your other answer first and I thought it was because we've reached some kind of maximum depth] Thanks, I see. Ok, if it's just string or binary based it will work from a correctness standpoint. I'd expect big performance problems with ad-hoc views (if they even exist here), but these shouldn't be used in production anyways. Also, I'd expect replication to take quite a bit longer because it needs to map every document with changes, so there's going to be a tradeoff between initialization time and replication time between the two approaches. I'm thinking it's going to be beneficial for larger databases to have a TouchDB 'server' somewhere, which constantly replicates with CouchDB and sends the devices a complete snapshot sqlite file for the initial setup. After that, they can talk to CouchDB directly. Otherwise it could take like half an hour to initialize a 50MB DB on a device, which is not really feasible.
    - greendestiny 14y ago
      In fact for a while you could only have adhoc views, but my knowledge is 6 months out of date. Yes definitely do that. I bundle the sqlite in the app store updates and then mount that as an external db and pull from itself - its a bit awkward but it worked. I had to write the external db stuff, but it was pretty easy.