3 ms·

As per the description, all updates must be replicated to a quorum of instances. If Charlie is on a plane without the ability to contact a quorum, he can't add

As per the description, all updates must be replicated to a quorum of instances. If Charlie is on a plane without the ability to contact a quorum, he can't add records in the first place. This is a fundamentally necessary tradeoff to provide strong consistency, as described by the CAP theorem.

unnouinceput 6y ago
In which case Charlie will have an additional local DB to record those records and when he gets back will use another protocol/method/system/whatever to add those new records? How about if everybody goes and adds records on same table? Here is a real life scenario that I had to deal with in the past. Technician (carpenters) goes to clients home to repair furniture in the middle of nowhere, so no internet. Adds the necessary paperwork which is pictures, declarations, contract (signed and scanned) to the Clients table. This company was employing hundreds of such technicians throughout the many counties of Germany, each with a laptop on them running this app which was the backbone for getting paid/do the work. And was not uncommon to have more than one carpenter go to client home and do the repairs. Since each carpenter was paid according to its own work, each of them would create entries in their local Clients table and when getting back to HQ their work was manually uploaded to central DB, and only after that they got paid. I automated that (that was the job, to eliminate the thousands of hours that carpenters were wasting manually). So given the above scenario, how is this system going to achieve that? Same table, and same client details even in table Clients, just different rows for different carpenters (foreign key to table Carpenters).
- wtallis 6y ago
  > So given the above scenario, how is this system going to achieve that? I don't think it is. You're describing a use case that is distributed but explicitly does not want to enforce consistency—you want offline workers to all be able to keep working, and you're enforcing consistency after the fact and outside of the database itself.
- renewiltord 6y ago
  This tool does not handle that problem. It is not meant to. It's for simultaneously available replicas. And this is the rare moment where thinking about replication vs synchronization as different is worthwhile. You usually replicate for failure tolerance and performance (this project only aims for the former).
- vorpalhex 6y ago
  As other commentors have mentioned, this tool is not intended for that kind of case. You want a tool like PouchDB which handles this kind of setup, but have a different set of tradeoffs (they're eventually consistent, not strongly consistent).

unnouinceput 6y ago

In which case Charlie will have an additional local DB to record those records and when he gets back will use another protocol/method/system/whatever to add those new records? How about if everybody goes and adds records on same table? Here is a real life scenario that I had to deal with in the past. Technician (carpenters) goes to clients home to repair furniture in the middle of nowhere, so no internet. Adds the necessary paperwork which is pictures, declarations, contract (signed and scanned) to the Clients table. This company was employing hundreds of such technicians throughout the many counties of Germany, each with a laptop on them running this app which was the backbone for getting paid/do the work. And was not uncommon to have more than one carpenter go to client home and do the repairs. Since each carpenter was paid according to its own work, each of them would create entries in their local Clients table and when getting back to HQ their work was manually uploaded to central DB, and only after that they got paid. I automated that (that was the job, to eliminate the thousands of hours that carpenters were wasting manually). So given the above scenario, how is this system going to achieve that? Same table, and same client details even in table Clients, just different rows for different carpenters (foreign key to table Carpenters).

wtallis 6y ago
> So given the above scenario, how is this system going to achieve that? I don't think it is. You're describing a use case that is distributed but explicitly does not want to enforce consistency—you want offline workers to all be able to keep working, and you're enforcing consistency after the fact and outside of the database itself.
renewiltord 6y ago
This tool does not handle that problem. It is not meant to. It's for simultaneously available replicas. And this is the rare moment where thinking about replication vs synchronization as different is worthwhile. You usually replicate for failure tolerance and performance (this project only aims for the former).
vorpalhex 6y ago
As other commentors have mentioned, this tool is not intended for that kind of case. You want a tool like PouchDB which handles this kind of setup, but have a different set of tradeoffs (they're eventually consistent, not strongly consistent).