4 ms·

>>What happens when two people share authentication (which will happen!) and access the app at the same time. If they both come from a different district and l

by oblib 7y ago

>>What happens when two people share authentication (which will happen!) and access the app at the same time. If they both come from a different district and log into CouchDB they'll either only write to their file (one db, multi-user) or write to a file (or files) in their db (db per user). If two users write to same file in same the db at the same time the DB will note the conflict and decide which data gets stored in the file. https://docs.couchdb.org/en/stable/replication/conflicts.html https://docs.couchdb.org/en/stable/replication/conflicts.htm...

nl 7y ago
> https://docs.couchdb.org/en/stable/replication/conflicts.html https://docs.couchdb.org/en/stable/replication/conflicts.htm... Yes, this is how I remember CouchDB working. It leaves the hard parts of conflic resolution up to the client app: Once you have retrieved all the conflicting revisions, your application can then choose to display them all to the user. Or it could attempt to merge them, write back the merged version, and delete the conflicting versions - that is, to resolve the conflict permanently. You do realize that SQL databases handle this automatically via locking schemes and transaction, right?
- oblib 7y ago
  The window is pretty small to create a conflict in a well designed CouchDB interface because of the way revisions are used. You should get the latest revision when you load the data for editing. And it's trivial to set a "locked" flag in a file being edited to prevent others from overwriting it if you have it configured so others can do that. In this particular use case there really should only be one authorized user who can edit the data file for each precinct so race conditions like you describe just don't exist. You can also use CouchDB's live sync feature to push the latest revision to everyone viewing the file in close to real time. So conflicts are really a non-issue here. By design they just don't happen.

by oblib 7y ago

nl 7y ago

> https://docs.couchdb.org/en/stable/replication/conflicts.html https://docs.couchdb.org/en/stable/replication/conflicts.htm... Yes, this is how I remember CouchDB working. It leaves the hard parts of conflic resolution up to the client app: Once you have retrieved all the conflicting revisions, your application can then choose to display them all to the user. Or it could attempt to merge them, write back the merged version, and delete the conflicting versions - that is, to resolve the conflict permanently. You do realize that SQL databases handle this automatically via locking schemes and transaction, right?

oblib 7y ago
The window is pretty small to create a conflict in a well designed CouchDB interface because of the way revisions are used. You should get the latest revision when you load the data for editing. And it's trivial to set a "locked" flag in a file being edited to prevent others from overwriting it if you have it configured so others can do that. In this particular use case there really should only be one authorized user who can edit the data file for each precinct so race conditions like you describe just don't exist. You can also use CouchDB's live sync feature to push the latest revision to everyone viewing the file in close to real time. So conflicts are really a non-issue here. By design they just don't happen.