1 | mongopatch [![Build Status](https://travis-ci.org/e-conomic/mongopatch.png?branch=master)](https://travis-ci.org/e-conomic/mongopatch)
|
2 | ==========
|
3 |
|
4 | MongoDB patching tool. Update and log mongodb documents.
|
5 |
|
6 | npm install -g mongopatch
|
7 |
|
8 |
|
9 | Writing patches
|
10 | ---------------
|
11 |
|
12 | Patches are written as separate modules, exposing a single patching function.
|
13 |
|
14 | ```javascript
|
15 | module.exports = function(patch) {
|
16 | // Specify which patching system version to use for this patch (required)
|
17 | patch.version('0.1.0');
|
18 |
|
19 | // Update all users that match the provided query.
|
20 | // The query is optional, if not provided all the documents
|
21 | // in the collection are processed.
|
22 | patch.update('users', { name: 'e-conomic' }, function(document, callback) {
|
23 | // The callback function should be called with the update to apply,
|
24 | // this can be any valid mongodb update query.
|
25 | callback(null, { $set: { email: 'e-conomic@e-conomic.com', associates: 'unknown' } });
|
26 | });
|
27 |
|
28 | // Register an after callback, to be run after each update.
|
29 | patch.after(function(update, callback) {
|
30 | var isValid = update.after.email === 'e-conomic@e-conomic.com';
|
31 |
|
32 | // Call the callback function with an error to abort the patching process.
|
33 | // Use this to guard against corrupted updates.
|
34 | callback(isValid ? null : new Error('Update failed'));
|
35 | });
|
36 | }
|
37 | ```
|
38 |
|
39 | The after callback gets an options map, containing the `before` and `after` documents, a `modfifed` flag (telling if there any changes between the two documents) and a `diff` object (the diff between the two documents).
|
40 |
|
41 | Another example where we process all users.
|
42 |
|
43 | ```javascript
|
44 | function shouldUpdate(document) {
|
45 | // ...
|
46 | }
|
47 |
|
48 | function update(document) {
|
49 | // ...
|
50 | }
|
51 |
|
52 | function isValid(document) {
|
53 | // ...
|
54 | }
|
55 |
|
56 | module.exports = function(patch) {
|
57 | patch.version('0.1.0');
|
58 |
|
59 | // All users are processed, since no filter query provided.
|
60 | patch.update('users', function(document, callback) {
|
61 | if(!shouldUpdate(document)) {
|
62 | // Calling the callback with no arguments, skips the document in the update process.
|
63 | return callback();
|
64 | }
|
65 |
|
66 | update(document);
|
67 |
|
68 | if(!isValid(document)) {
|
69 | // Validate document before performing the actual update in the database.
|
70 | // Passing an error as first argument, aborts the patching process,
|
71 | // and can leave the database in inconsistent state.
|
72 | return callback(new Error('Invalid document'));
|
73 | }
|
74 |
|
75 | // Apply the update, by overwritting the whole document
|
76 | callback(null, document);
|
77 | });
|
78 | }
|
79 | ```
|
80 |
|
81 | It's also possible to register `setup` and `teardown` hooks, executed before and after the patch is run. The `teardown` callback gets called with an additional stats object, containg accumulated details about the patch.
|
82 |
|
83 | ```javascript
|
84 | patch.setup(function(callback) {
|
85 | // Pass an error object as first argument to callback, to terminate execution.
|
86 | callback();
|
87 | });
|
88 | ```
|
89 |
|
90 | ```javascript
|
91 | patch.teardown(function(stats, callback) {
|
92 | // Stats contains details about execution time, number of modified documents and average speed.
|
93 | callback();
|
94 | });
|
95 | ```
|
96 |
|
97 | Runing patches
|
98 | --------------
|
99 |
|
100 | Run patches using the `mongopatch` command-line tool. Basic usage:
|
101 |
|
102 | mongopatch path/to/patch.js --db "..." --dry-run --log-db "..."
|
103 |
|
104 | Available options (too see a full list of options, run `mongopatch` without any arguments).
|
105 |
|
106 | - **db**: MongoDB connection string (e.g. `user:password@localhost:27017/development` or `development`).
|
107 | - **log-db**: MongoDB connection string for the log database. When provided a version of the document is stored before and after the update.
|
108 | - **dry-run**: Do not perform any changes in the database. Changes are performed on copy of the documents and stored in the log db (if available).
|
109 | - **parallel**: Run the patch with given parallelism. It may run the patch faster.
|
110 | - **update**: Run the patch with one of the available update modes: `dummy`, `query` or `document` (default).
|
111 |
|
112 | #### Update option
|
113 |
|
114 | Three update modes are available. `query` and `document` both perform real updates on the database. `dummy` mode is the same as specifying the `--dry-run` option. Note also that `--dry-run` overrides `--update`.
|
115 |
|
116 | When performing updates on real data, external changes may occur, modifying the documents as they are being processed. When mongopatch is started it fetches all the documents matching the provided query. These are loaded in batches and there can be a significant amount of time between, when a document is loaded and when the actual update is performed. To prevent external updates from conflicting with patching two strategies are employed.
|
117 |
|
118 | The `query` mode uses the document's `_id` property and the query, originally provided to the `patch.update` method, as the criteria for finding and modifying the document (`findAndModify` MongoDB command). This means if the document has been changed externally, so that it no longer satisfies the query, it will be skipped. Other external changes to the document aren't considered.
|
119 |
|
120 | The `document` mode, on the other hand, uses the whole document as the criteria. Any external changes to document will prevent the document from being patched. If that occurs, the document is fetched again using the `_id` property and the original query (similiar when in `query` mode), and run through the worker function again (the function passed to `patch.update`). If the worker function returns a modifier, the whole proccess is repeated with the new document and modifier. This has the consequence, that the worker function can be called with the same document multiple times in arbitrary order. This could affect patches with some form of state (e.g. counting number of documents by incrementing a counter every time the worker function has been called).
|
121 |
|
122 | Runing updates in query mode:
|
123 |
|
124 | mongopatch path/to/patch.js --db "..." --log-db "..." --update query
|
125 |
|
126 | #### CLI
|
127 |
|
128 | The tool has a simple command-line interface, where it is possible to track progress and accumulated changes done to the documents. The diff shows how many times a property has been added, updated or removed between the original and the updated documents (note that all array changes are grouped).
|
129 |
|
130 | When running on a live database, where external changes can occur, the progress indicator may be incorrect, as documents can be added or removed. Also skipping documents in `patch.update` causes the progress to fall behind.
|
131 |
|
132 | Log database
|
133 | ------------
|
134 |
|
135 | When a log database is available, a collection is created for every patch run. A document in the patch collection, contains data about the applied update. The `before` key points to the original document, `after` to the updated document, `modified` is a boolean flag telling if there were any changes and `diff` the difference between the `before` and `after` document (if `modified` is false, this is going to be an empty object). It also includes additional meta data.
|
136 |
|
137 | ```javascript
|
138 | {
|
139 | "before": {
|
140 | "_id": ObjectId("507d2a650ea37a02000001ae"),
|
141 | "name": "e-conomic",
|
142 | "associates": "debitoor"
|
143 | },
|
144 | "after": {
|
145 | "_id": ObjectId("507d2a650ea37a02000001ae"),
|
146 | "name": "e-conomic",
|
147 | "associates": "unknown",
|
148 | "email": "e-conomic@e-conomic.com"
|
149 | },
|
150 | "modified": true,
|
151 | "skipped": false,
|
152 | "diff": { // diff is a nested object, where leafs can have one of the three values added, updated, removed
|
153 | "associates": "updated",
|
154 | "email": "added"
|
155 | },
|
156 | "createdAt": ISODate("2013-12-17T15:28:14.737Z"), // when was the log document created
|
157 | "collection": "development.users", // full collection name
|
158 | "modifier": "{ \"$set\": { \"email\": \"e-conomic@e-conomic.com\" } }", // stringified modifier (passed to the callback in patch.update)
|
159 | "query": "{ \"name\": \"e-conomic\" }" // stringified query (passed to patch.update function)
|
160 | }
|
161 | ```
|
162 |
|
163 | In some cases if an error occures during the patching, an `error` object is added to the log document, containing the error message and stack.
|
164 |
|
165 | Release notes
|
166 | -------------
|
167 |
|
168 | #### Version 0.7.0
|
169 |
|
170 | - Added `document` update mode. Uses the whole document as query when performing the update (optimistic locking). This is now the default mode. [Issue #3](https://github.com/e-conomic/mongopatch/issues/3).
|
171 | - Validate provided database and collection. Nonexsting database or collection raise an error. [Issue #5](https://github.com/e-conomic/mongopatch/issues/5).
|
172 | - Validate command-line arguments. Unknown arguments raise an error. [Issue #4](https://github.com/e-conomic/mongopatch/issues/4).
|
173 |
|
174 | #### Version 0.6.0
|
175 |
|
176 | - Fix command-line argument parsing bug where `--dry-run` and `--parallel` didn't work.
|
177 | - Mixin provided query when updating document, to make sure the document still statisfies the criteria. [Issue #3](https://github.com/e-conomic/mongopatch/issues/3).
|