Ghost/core/server/models/plugins/index.js

module.exports = {
    filter: require('./filter'),
    includeCount: require('./include-count'),
    pagination: require('./pagination'),
    collision: require('./collision'),
    transactionEvents: require('./transaction-events')
};
Move bookshelf plugins into own folder 2015-11-11 21:24:24 +03:00			`module.exports = {`
Filter plugin with enforce/default logic refs #5614, #5943 - adds a new 'filter' bookshelf plugin which extends the model - the filter plugin provides handling for merging/combining various filters (enforced, defaults and custom/user-provided) - the filter plugin also handles the calls to gql - post processing is also moved to the plugin, to be further refactored/removed in future - adds tests showing how filter could be abused prior to this commit 2015-11-11 20:52:44 +03:00			`filter: require('./filter'),`
Move bookshelf plugins into own folder 2015-11-11 21:24:24 +03:00			`includeCount: require('./include-count'),`
✨ post update collision detection (#8328) (#8362) 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 2017-04-19 16:53:23 +03:00			`pagination: require('./pagination'),`
Fixed model events and transactions (#9524) no issue - if multiple queries run in a transaction, the model events are triggered before the txn finished - if the txn rolls back, the events are anyway emitted - the events are triggered too early - solution: - `emitChange` needs to detect that a transaction is happening - it listens on a txn event to determine if events should be triggered 2018-04-06 19:19:45 +03:00			`collision: require('./collision'),`
			`transactionEvents: require('./transaction-events')`
Move bookshelf plugins into own folder 2015-11-11 21:24:24 +03:00			`};`