My question is this: If two users are modifying records in a table like this, and one edits a field, then exits that field while it is set to auto-save once that happens, does the field update for the other user without them having to refresh their page?
I’d guess the tables’ information is put in client memory once the page loads, so the records wouldn’t update like that, but I have no working examples to test this with.
If it won’t do that natively, is there a way to make it do that with some other feature of JavaScript?
Yes it’s possible, no it isn’t easy and look at websockets because then you can push the change to every other connected client
It’s true that it is first put into memory, but noone is stopping you to send the change to the server in your autosave function Once it’s on the server you just need a way to push it to all other clients, and that’s where websockets come in.
If you’re interested I think I still have a decently broke github repo somewhere that’s an SPA framework that uses AJAX and Jquery and passes back and forth with PHP.
It doesn’t have websocket integration, but I was getting ready to code it in before I got too busy to work on it anymore.
Thanks, this will be educational for me. I might have issues applying things I learn here to Laravel, but I think it’s just as important to learn a framework’s underlying things as it is to understand how the framework itself handles the interactions between the different technologies it uses.
If you can’t or don’t want to use WebSockets in a project you can also set an interval to call the server for changes and apply them. It wouldn’t be a 100% live for every connection, but it would work for older browsers without WebSocket support.
But please, for the love of all that is holy, don’t use setTimeout() or setInterval() for that (or rather only as a fallback) and use requestAnimationFrame() instead. Obviously detect if it’s supported (because chances are requestAnimationFrame() isn’t supported either if WebSocket isn’t supported), and if not resort to the former as a last resort because it’s basically terrible.
Though non of that should be an issue if you’re doing a reasonably recent deploy.
It wouldn’t be syncing their edits. Just what is committed. Figuring there’s an auto-save when the field is done being edited (i.e. the user selects another field or hits escape or whatever), that’s when the change is actually committed.
If someone else is also editing the same field but hasn’t committed yet, I can do a couple things to alleviate issues.
Have the update get pushed to their client anyway, but as a popup letting them know someone else has changed the field while they were editing it.
Check if the field changed when the user tries to commit and do the same thing (let them know)
I can’t think of another way that works better or as good as those two.
When either of those happen, I’ll just give the user 3 options.
Lose their edit in favor of the other user.
Overwrite the other user’s edit with their own.
Merge the two and commit that.
I figure that should handle most things. This is something that 60 people would be using, at most, with 10,000+ records and only certain people who will always be near each other likely to access the same thing at the same time.
I can… just don’t let a second person edit in the first place.
When someone starts editing you tell all other clients to lock the field, making it non-editable, or read-only, however you want to call it.
I don’t know how big your fields are, but writing a custom merger is probably a pain in the rear.
The issue I’m solving by producing this website is that we currently use Microsoft Access to directly access, view, and edit these database records. When one person has a record locked for editing, and another tries to sort, or something similar, it locks up the whole database.
It isn’t a good thing for so many reasons. But legacy stuff yo.
Good idea. I’ll probably just do that then.
I was just going to take whoever went first’s edit -> append whoever went second -> commit that and have a note saying to reconcile manually between the two people. i.e. one calls the other and they decide what the field should actually be or something.
Most fields are gonna be simple things like a state, status, date, or other repeatable items. The only field I would’ve expected the merge to matter much on would be the comment fields for obvious reasons.
Effectively you have to ask the server. Because if two people start editing a field at the same time, both are able to start the edit before the server has told them the other person is editing the field.
It’s mostly okay because you don’t have to wait for an answer, so you can assume that nobody else is editing the field until the server tells you otherwise. But then can you make the same assumption when committing?
Once it’s on the server you just need a way to push it to all other clients, and that’s where websockets come in.
Not sure why I didn’t think of that.