|
1 |
| - |
2 |
| -import MongoCollection from './MongoCollection'; |
3 |
| -import MongoSchemaCollection from './MongoSchemaCollection'; |
| 1 | +import MongoCollection from './MongoCollection'; |
| 2 | +import MongoSchemaCollection from './MongoSchemaCollection'; |
4 | 3 | import {parse as parseUrl, format as formatUrl} from '../../../vendor/mongodbUrl';
|
| 4 | +import _ from 'lodash'; |
5 | 5 |
|
6 | 6 | let mongodb = require('mongodb');
|
7 | 7 | let MongoClient = mongodb.MongoClient;
|
@@ -78,6 +78,52 @@ export class MongoStorageAdapter {
|
78 | 78 | });
|
79 | 79 | });
|
80 | 80 | }
|
| 81 | + |
| 82 | + // Remove the column and all the data. For Relations, the _Join collection is handled |
| 83 | + // specially, this function does not delete _Join columns. It should, however, indicate |
| 84 | + // that the relation fields does not exist anymore. In mongo, this means removing it from |
| 85 | + // the _SCHEMA collection. There should be no actual data in the collection under the same name |
| 86 | + // as the relation column, so it's fine to attempt to delete it. If the fields listed to be |
| 87 | + // deleted do not exist, this function should return successfully anyways. Checking for |
| 88 | + // attempts to delete non-existent fields is the responsibility of Parse Server. |
| 89 | + |
| 90 | + // Pointer field names are passed for legacy reasons: the original mongo |
| 91 | + // format stored pointer field names differently in the database, and therefore |
| 92 | + // needed to know the type of the field before it could delete it. Future database |
| 93 | + // adatpers should ignore the pointerFieldNames argument. All the field names are in |
| 94 | + // fieldNames, they show up additionally in the pointerFieldNames database for use |
| 95 | + // by the mongo adapter, which deals with the legacy mongo format. |
| 96 | + |
| 97 | + // This function is not obligated to delete fields atomically. It is given the field |
| 98 | + // names in a list so that databases that are capable of deleting fields atomically |
| 99 | + // may do so. |
| 100 | + |
| 101 | + // Returns a Promise. |
| 102 | + |
| 103 | + // This function currently accepts the collectionPrefix and adaptive collection as a paramater because it isn't |
| 104 | + // actually capable of determining the location of it's own _SCHEMA collection without having |
| 105 | + // the collectionPrefix. Also, Schemas.js, the caller of this function, only stores the collection |
| 106 | + // itself, and not the prefix. Eventually Parse Server won't care what a SchemaCollection is and |
| 107 | + // will just tell the DB adapter to do things and it will do them. |
| 108 | + deleteFields(className: string, fieldNames, pointerFieldNames, collectionPrefix, adaptiveCollection) { |
| 109 | + const nonPointerFieldNames = _.difference(fieldNames, pointerFieldNames); |
| 110 | + const mongoFormatNames = nonPointerFieldNames.concat(pointerFieldNames.map(name => `_p_${name}`)); |
| 111 | + const collectionUpdate = { '$unset' : {} }; |
| 112 | + mongoFormatNames.forEach(name => { |
| 113 | + collectionUpdate['$unset'][name] = null; |
| 114 | + }); |
| 115 | + |
| 116 | + const schemaUpdate = { '$unset' : {} }; |
| 117 | + fieldNames.forEach(name => { |
| 118 | + schemaUpdate['$unset'][name] = null; |
| 119 | + }); |
| 120 | + |
| 121 | + return adaptiveCollection.updateMany({}, collectionUpdate) |
| 122 | + .then(updateResult => { |
| 123 | + return this.schemaCollection(collectionPrefix) |
| 124 | + }) |
| 125 | + .then(schemaCollection => schemaCollection.updateSchema(className, schemaUpdate)); |
| 126 | + } |
81 | 127 | }
|
82 | 128 |
|
83 | 129 | export default MongoStorageAdapter;
|
|
0 commit comments