-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concurrent multiple edits results in loss of data #2
Comments
Yes you're right, this can definitely happen if the server for editing is made available to multiple users. I have not tried to address this, as the intended use case was that the HTML file be kept under version control and edited "offline" by one user at a time. Then any conflicting changes would have to be sorted out by resolving merge conflicts. This was not stated clearly in the instructions so I'm about to release v1.7.4 to improve that. I'm actually not sure yet how to go from the current "single-user only" editing functionality to something that supports multiple concurrent users. It feels like that would require a real database rather than writing to a file on disk, as well as a proper web server. I don't want to encourage people to run the current server and expose it to many users, as it's probably not secure enough for that. Thanks for raising this, and if exposing the editor to multiple users makes sense for your use case, then please provide more details about this to help me understand, otherwise I don't think I would accept a PR for the reasons above. |
@hilverd - Thanks for the response. We've hosted this repo internally in our organisation and are running it in edit mode for everyone. The use case is that we want everyone to contribute to the glossary instead of a single user managing the entire glossary. Within a team/company, just having a single author own the entire glossary becomes challenging. Crowdsourcing this seems to be a better way to build a glossary and maintain it (similar terms to wiki). I love the simplicity of setting this up and don't want to compromise on that. The sed command to run the javascript code under node is super smart and geeky. My proposal is to check with the server once before sending the PATCH request, so that we reduce (might not completely eliminate) the chances of conflicts. For example, what I'm proposing is making changes to the Another possible solution is to explore if we can use the Last-Modified HTTP header and leverage that to fetch from the server or at least warn users there are new changes since they've loaded the page. Happy to build the basic version of this and send a PR. |
Thanks for the additional information and the kind words. OK, I'm fine with having improvements in this direction as it does sound useful. (I might add an additional note somewhere to make it very clear that the server for editing should only be exposed to trusted users.) I'm happy to look at a PR if you create one -- thanks! -- although I might still be a bit slow to respond. |
Hi,
I see that two different browser sessions editing the glossary at the same time results in loss of data (the last save is what is stored in disk and other changes are ignored).
I plan to solve this by doing a GET request to fetch the latest data before sending the PATCH request. While this still doesn't give a 100% safety against many concurrent users, might work for most of the users. Let me know if that approach works well or is there a better way to do this.
The text was updated successfully, but these errors were encountered: