couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Design considerations
Date Tue, 09 Nov 2010 19:40:30 GMT
Thanks Zach, that's most helpful.

Regarding the number of databases that can be open at once, how
quickly are the connections closed down? If a user loads a web page
(via a server side application layer) which accesses their database
for example, is their connection closed pretty much immediately, or
does it linger around for a while? If so ... how long is "a while"?
Does this make sense? I'll give some thought to the sharding we could
use to keep within sensible limits in the meantime.

Shame about COPY not working between databases, but I guess not
surprising. Replication filters sound interesting ... and looking at
the docs I see I can do named document replication, which is
effectively a COPY and hence perfect I think?

> Finally, you'll really need to consider if/how/when folks will update
> this data. If two users both want to update the same document on their
> slices, and replicate their modifications back to the central
> database, you're going to have to build conflict resolution into your
> system.

Experience shows that data tends to be edited shortly after document
creation and rarely thereafter. Equally it's almost always edited by
the person that created it - so the two users simultaneously editing a
document scenario will be extraordinarily rare, but we will indeed
need to handle conflict resolution if it happens. I've seen that in
action with some of my tests and think that should all be fine.

Sorry, this was a bit of a waffle post ... I'm just thinking out loud
while I ponder the system architecture.


View raw message