Skip to content
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

Open
sp2hari opened this issue Jul 5, 2022 · 3 comments
Open

Concurrent multiple edits results in loss of data #2

sp2hari opened this issue Jul 5, 2022 · 3 comments

Comments

@sp2hari
Copy link

sp2hari commented Jul 5, 2022

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.

@hilverd
Copy link
Owner

hilverd commented Jul 8, 2022

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.

@sp2hari
Copy link
Author

sp2hari commented Jul 10, 2022

@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 patchHtmlFile code in CreateOrEdit.elm. In that function, can we fetch from the server and update the glossaryItems (we need to be smart about the diff) before sending a PATCH request. This might avoid loss of data when multiple users are trying to add glossary items.

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.

@hilverd
Copy link
Owner

hilverd commented Jul 16, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants