From a2a6248bd18b13874a37fff9b6cf983a520b077d Mon Sep 17 00:00:00 2001 From: rachael Date: Fri, 19 Jan 2018 17:17:06 -0800 Subject: [PATCH 1/3] Remove old LiveDB commented documentation --- README.md | 269 +----------------------------------------------------- 1 file changed, 1 insertion(+), 268 deletions(-) diff --git a/README.md b/README.md index a9847b911..69770ed33 100644 --- a/README.md +++ b/README.md @@ -10,12 +10,11 @@ documents. It is the realtime backend for the [DerbyJS web application framework](http://derbyjs.com/). For questions, discussion and announcements, join the [ShareJS mailing -list](https://groups.google.com/forum/?fromgroups#!forum/sharejs). +list](https://groups.google.com/forum/?fromgroups#!forum/sharejs) or [check the FAQ](./docs/faq.md). Please report any bugs you find to the [issue tracker](https://github.com/share/sharedb/issues). - ## Features - Realtime synchronization of any JSON document @@ -322,272 +321,6 @@ after a sequence of diffs are handled. (Only fires on subscription queries) `query.extra` changed. - - - ## Error codes ShareDB returns errors as plain JavaScript objects with the format: From 210de8c53af9e4d4913f9fccd9aed57675357357 Mon Sep 17 00:00:00 2001 From: rachael Date: Fri, 19 Jan 2018 17:17:20 -0800 Subject: [PATCH 2/3] Add faq --- docs/faq.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 docs/faq.md diff --git a/docs/faq.md b/docs/faq.md new file mode 100644 index 000000000..45cac5f92 --- /dev/null +++ b/docs/faq.md @@ -0,0 +1,9 @@ +# FAQ + +## Is it possible to completely delete documents from the db? + +No, it is not possible to use the ShareDB API to fully delete data and the op log is kept forever by default. + +ShareDB should correctly deal with all cases where ops have been removed, and it will not get into a corrupt state if you delete ops or a snapshot. Of course, if you delete ops and then a client reconnects needing those ops, you will break that client and it will be unable to submit any pending changes or bring itself up to date from its current state. It is much safer to never delete any ops and, if you are going to clean up ops and/or snapshots, you'll need to ensure that no clients will never need them again or deal with the error appropriately. + +If you want to permanently delete data, you can delete from your persistent datastore directly. For example, if you're using MongoDB you can delete the data by connecting to Mongo directly, not the ShareDB API. Note if you are going to delete data be sure that you clean up not just the document snapshot but all operations associated with that document. From 4bb6f281d115a7e6f78dfd9802b0b7e2af5c6cdf Mon Sep 17 00:00:00 2001 From: Nate Smith Date: Wed, 31 Jan 2018 13:20:44 -0800 Subject: [PATCH 3/3] Update faq.md --- docs/faq.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/faq.md b/docs/faq.md index 45cac5f92..a8e116f76 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -2,8 +2,8 @@ ## Is it possible to completely delete documents from the db? -No, it is not possible to use the ShareDB API to fully delete data and the op log is kept forever by default. +No, it is not possible to use the ShareDB API to fully delete data. In addition, the operation log is kept forever by default. -ShareDB should correctly deal with all cases where ops have been removed, and it will not get into a corrupt state if you delete ops or a snapshot. Of course, if you delete ops and then a client reconnects needing those ops, you will break that client and it will be unable to submit any pending changes or bring itself up to date from its current state. It is much safer to never delete any ops and, if you are going to clean up ops and/or snapshots, you'll need to ensure that no clients will never need them again or deal with the error appropriately. +Maintaining persistence of snapshots and ops means that ShareDB can correctly deal with all cases where ops have been removed. Permanently removing the snapshot document could result in a corrupt state in some edge cases by not maintaining the current document version, which must be incremented on each commit. As well, if you delete ops and then a client reconnects needing those ops, you will break that client and it will be unable to submit any pending changes or bring itself up to date from its current state. If your usecase calls for complete deletion of operations, you'll need to ensure that no clients will ever need them again or deal with the error appropriately. -If you want to permanently delete data, you can delete from your persistent datastore directly. For example, if you're using MongoDB you can delete the data by connecting to Mongo directly, not the ShareDB API. Note if you are going to delete data be sure that you clean up not just the document snapshot but all operations associated with that document. +You can currently delete from your persistent datastore directly. For example, if you're using MongoDB you can delete the data by connecting to Mongo directly, not via the ShareDB API. If you do delete snapshot data, be sure that you delete not just the document snapshot but all operations associated with that document. Having operations with no corresponding snapshot would result in a corrupt state.