✨ post update collision detection #8328

kirrg001 · 2017-04-13T17:54:26Z

If two users edit the same post, it can happen that they override each others content or post settings. With this PR this won't happen anymore.
This PR can detect post changes and tag changes and if a collision is detected, the user will receive an error back. Each commit should be clear and has enough context to understand the required changes. Some tests i have added are quite complex because they simulate collision cases we have to care about. These tests are not sooo good to read. But can't change this, because they simulate a complex use case. You will see if you go through the commits.

What i didn't test is the rest of the functionality in Ghost. Will do before we release the new LTS version.

closes TryGhost#5599 - add a new bookshelf plugin to detect these changes - use the `changed` object of bookshelf -> we don't have to create our own diff - compare client and server updated_at field - run editing posts in a transaction (see comments in code base)

- `updateTags` for adding posts on `onCreated` - happens after the post was inserted --> it's "okay" to attach the tags afterwards on insert --> there is no need to add collision for inserting data --> it's very hard to move the updateTags call to `onCreating`, because the `updateTags` function queries the database to look up the affected post - `updateTags` while editing posts on `onSaving` - all operations run in a transactions and are rolled back if something get's rejected

- there was no support for error codes yet - added a simpler condition into our LTS error handler

- if two queries happening in a transaction we have to signalise knex/mysql that we select for an update - otherwise the following case happens: >> you fetch posts for an update >> a user requests comes in and updates the post (e.g. sets title to "X") >> you update the fetched posts, title would get overriden to the old one

- use a transaction for listener updates - signalise forUpdate - write a complex test

@todo

- publish endpoint runs in a transaction - add complex test - @todo: right now scheduling api uses posts api, therefor we had to extend the options for api's >> allowed to pass transactions through it >> but these are only allowed if defined from outside {opts: [...]} >> so i think this is fine and not dirty >> will wait for opinions >> alternatively we have to re-write the scheduling endpoint to use the models directly

kirrg001 · 2017-04-14T11:34:36Z

This is ready for review 🙀

ErisDS

I have a couple of small questions and one minor change to the error message.

I tested this and it seemed to work well 👍

core/server/models/plugins/collision.js

+                if (Object.keys(changed).length) {
+                    if (clientUpdatedAt.diff(serverUpdatedAt) !== 0) {
+                        err = new errors.InternalServerError('Uh-oh. We already have a newer version of this post saved.' +
+                            'To prevent losing your text, please copy your changes somewhere else and then refresh this page.');


core/server/models/plugins/collision.js

+                    serverUpdatedAt = moment(self.serverData.updated_at);
+
+                if (Object.keys(changed).length) {
+                    if (clientUpdatedAt.diff(serverUpdatedAt) !== 0) {


core/server/models/base/index.js

@@ -459,7 +462,7 @@ ghostBookshelf.Model = ghostBookshelf.Model.extend({

        return model.fetch(options).then(function then(object) {
            if (object) {
-                return object.save(data, options);
+                return object.save(data, _.merge({method: 'update'}, options));


core/server/models/post.js

        options = options || {};

+        if (options.transacting) {
+            return editPost(data, options);


core/server/api/schedules.js

-                    if (publishedAtMoment.diff(moment(), 'minutes') > publishAPostBySchedulerToleranceInMinutes) {
-                        return Promise.reject(new errors.NotFoundError(i18n.t('errors.api.job.notFound')));
-                    }
+                // CASE: apiPosts.read and apiPosts.edit happen in a transaction, signalise `forUpdate` to knex


refs TryGhost/Ghost#8331, TryGhost/Ghost#8328 - prevents auto-save save if nothing has changed, this avoides unnecessary collision errors when reading a post that another user is editing

@todo

closes TryGhost#5599 If two users edit the same post, it can happen that they override each others content or post settings. With this change this won't happen anymore. ✨ Update collision for posts - add a new bookshelf plugin to detect these changes - use the `changed` object of bookshelf -> we don't have to create our own diff - compare client and server updated_at field - run editing posts in a transaction (see comments in code base) 🙀 update collision for tags - `updateTags` for adding posts on `onCreated` - happens after the post was inserted --> it's "okay" to attach the tags afterwards on insert --> there is no need to add collision for inserting data --> it's very hard to move the updateTags call to `onCreating`, because the `updateTags` function queries the database to look up the affected post - `updateTags` while editing posts on `onSaving` - all operations run in a transactions and are rolled back if something get's rejected - Post model edit: if we push a transaction from outside, take this one ✨ introduce options.forUpdate - if two queries happening in a transaction we have to signalise knex/mysql that we select for an update - otherwise the following case happens: >> you fetch posts for an update >> a user requests comes in and updates the post (e.g. sets title to "X") >> you update the fetched posts, title would get overriden to the old one use options.forUpdate and protect internal post updates: model listeners - use a transaction for listener updates - signalise forUpdate - write a complex test use options.forUpdate and protect internal post updates: scheduling - publish endpoint runs in a transaction - add complex test - @todo: right now scheduling api uses posts api, therefor we had to extend the options for api's >> allowed to pass transactions through it >> but these are only allowed if defined from outside {opts: [...]} >> so i think this is fine and not dirty >> will wait for opinions >> alternatively we have to re-write the scheduling endpoint to use the models directly

@todo

closes #5599 If two users edit the same post, it can happen that they override each others content or post settings. With this change this won't happen anymore. ✨ Update collision for posts - add a new bookshelf plugin to detect these changes - use the `changed` object of bookshelf -> we don't have to create our own diff - compare client and server updated_at field - run editing posts in a transaction (see comments in code base) 🙀 update collision for tags - `updateTags` for adding posts on `onCreated` - happens after the post was inserted --> it's "okay" to attach the tags afterwards on insert --> there is no need to add collision for inserting data --> it's very hard to move the updateTags call to `onCreating`, because the `updateTags` function queries the database to look up the affected post - `updateTags` while editing posts on `onSaving` - all operations run in a transactions and are rolled back if something get's rejected - Post model edit: if we push a transaction from outside, take this one ✨ introduce options.forUpdate - if two queries happening in a transaction we have to signalise knex/mysql that we select for an update - otherwise the following case happens: >> you fetch posts for an update >> a user requests comes in and updates the post (e.g. sets title to "X") >> you update the fetched posts, title would get overriden to the old one use options.forUpdate and protect internal post updates: model listeners - use a transaction for listener updates - signalise forUpdate - write a complex test use options.forUpdate and protect internal post updates: scheduling - publish endpoint runs in a transaction - add complex test - @todo: right now scheduling api uses posts api, therefor we had to extend the options for api's >> allowed to pass transactions through it >> but these are only allowed if defined from outside {opts: [...]} >> so i think this is fine and not dirty >> will wait for opinions >> alternatively we have to re-write the scheduling endpoint to use the models directly

kirrg001 added the LTS label Apr 13, 2017

kirrg001 force-pushed the feature/update-collision branch 2 times, most recently from 4a2f307 to 807afc1 Compare April 14, 2017 11:22

kirrg001 added 8 commits April 14, 2017 13:26

🙈 jscs/jshint

b68fbaf

Ensure error code is forwarded to the client

d1b89b4

- there was no support for error codes yet - added a simpler condition into our LTS error handler

Post model edit: if we push a transaction from outside, take this one

95151ca

use options.forUpdate and protect internal post updates: model listeners

3cf5cef

- use a transaction for listener updates - signalise forUpdate - write a complex test

kirrg001 force-pushed the feature/update-collision branch from 807afc1 to 558aff8 Compare April 14, 2017 11:26

kirrg001 changed the title ~~[WIP] ✨ post update collision detection~~ ✨ post update collision detection Apr 14, 2017

kirrg001 assigned kevinansfield and ErisDS Apr 14, 2017

ErisDS requested changes Apr 17, 2017

View reviewed changes

Change error message!

82f7da8

ErisDS approved these changes Apr 17, 2017

View reviewed changes

Optimise comments

fbe2e48

kevinansfield mentioned this pull request Apr 17, 2017

don't auto-save posts if there are no changes TryGhost/Admin#648

Merged

kevinansfield merged commit ae7ad56 into TryGhost:lts Apr 17, 2017

kevinansfield deleted the feature/update-collision branch April 17, 2017 17:58

kirrg001 mentioned this pull request Apr 19, 2017

✨ post update collision detection #8362

Merged

ErisDS removed their assignment Jun 22, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

✨ post update collision detection #8328

✨ post update collision detection #8328

kirrg001 commented Apr 13, 2017 •

edited

Loading

kirrg001 commented Apr 14, 2017

ErisDS left a comment

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

✨ post update collision detection #8328

✨ post update collision detection #8328

Conversation

kirrg001 commented Apr 13, 2017 • edited Loading

kirrg001 commented Apr 14, 2017

ErisDS left a comment

Choose a reason for hiding this comment

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

kirrg001 commented Apr 13, 2017 •

edited

Loading