Transactions should be helpful here:
So if everything (including operation on remote server) goes right, your database will be updated, if not - all DB changes will be rolled back
@marekmurawski It's not a goal.
I want to avoid overwriting data by a second person. If I start inserting photo, and You start inserting photo before i saved changes, my changes will be overwrite by You because You read article before I saved it.
FR - First Request. SR - Second Request. Article content = Test.
In point 3 SR should get "Test. Made by FR.". So SR should wait until FR save their changes before he (SR) can read.
In this case you should make some custom locking mechanism. An idea would be to set
article.locked_at and maybe
locked_by_user_id timestamp properties at the moment when first user opens it for editing. You would need to check if article is locked before providing edit form and before storing changes. Of course the first user might start editing but not save changes at all - therefore the time-based
locked_at - so the lock would expire within certain time of inactivity.
Another option would be to save revisions of articles in a separate table. This way any single edit would be accessible in history.
These are just free thoughts... maybe someone wiser will help you more :)
What about locking in database layer? I found this, but I don't know how can I use it: http://laravel.com/docs/queries#pessimistic-locking
Edit: In InnoDB engine i can use DB::transaction() and lockForUpdate(), but in articles table i need MyISAM for full-text search.
So, implementing custom lock mechanism as @marekmurawski said, is the only solution?
one common method of doing this is to manage a data-versioning protocol yourself. For example,
:myDataVersion is what came back when you loaded the record.
So, if user A reads a record, he will get a dataVersion of,say 5. So will user B. User A then updates the record and the record's dataVersion becomes 6.
Some time later, user B goes to update that record but this will not succeed because the WHERE clause will fail. He is checking for a dataVersion of 5 but the record now has 6.
The above works well where you have control of the SQL UPDATE statement. I have yet to figure out how to alter the UPDATE SQL generated by Laravel, so that it contains the above WHERE addition.
Sign in to participate in this thread!
We'd like to thank these amazing companies for supporting us