Revert "Merge branch 'alpha' into pr/8332"

This reverts commit a576f72, reversing
changes made to d156f29.

Author: mtrezza

.eslintrc.json

@@ -5,14 +5,13 @@
         "node": true,
         "es6": true
     },
-    "parser": "@babel/eslint-parser",
+    "parser": "babel-eslint",
     "plugins": [
         "flowtype"
     ],
     "parserOptions": {
         "ecmaVersion": 6,
-        "sourceType": "module",
-        "requireConfigFile": false
+        "sourceType": "module"
     },
     "rules": {
         "indent": ["error", 2, { "SwitchCase": 1 }],

.github/workflows/ci.yml

@@ -1,11 +1,11 @@
 name: ci
 on:
   push:
-    branches: [ release*, alpha, beta ]
+    branches: [ release, alpha, beta ]
   pull_request:
-    branches: [ release*, alpha, beta ]
+    branches: [ release, alpha, beta ]
 env:
-  NODE_VERSION: 19.3.0
+  NODE_VERSION: 18.12.1
   PARSE_SERVER_TEST_TIMEOUT: 20000
 jobs:
   check-code-analysis:
@@ -137,32 +137,32 @@ jobs:
       - name: Check NPM lock file version
         uses: mansona/npm-lockfile-version@v1
         with:
-          version: 2
+          version: 1
   check-mongo:
     strategy:
       matrix:
         include:
           - name: MongoDB 4.2, ReplicaSet
             MONGODB_VERSION: 4.2.19
             MONGODB_TOPOLOGY: replicaset
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: MongoDB 4.4, ReplicaSet
             MONGODB_VERSION: 4.4.13
             MONGODB_TOPOLOGY: replicaset
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: MongoDB 5, ReplicaSet
             MONGODB_VERSION: 5.3.2
             MONGODB_TOPOLOGY: replicaset
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: MongoDB 6, ReplicaSet
             MONGODB_VERSION: 6.0.2
             MONGODB_TOPOLOGY: replicaset
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: Redis Cache
             PARSE_SERVER_TEST_CACHE: redis
             MONGODB_VERSION: 4.4.13
             MONGODB_TOPOLOGY: standalone
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: Node 14
             MONGODB_VERSION: 4.4.13
             MONGODB_TOPOLOGY: standalone
@@ -171,10 +171,6 @@ jobs:
             MONGODB_VERSION: 4.4.13
             MONGODB_TOPOLOGY: standalone
             NODE_VERSION: 16.18.1
-          - name: Node 18
-            MONGODB_VERSION: 4.4.13
-            MONGODB_TOPOLOGY: standalone
-            NODE_VERSION: 18.12.1
       fail-fast: false
     name: ${{ matrix.name }}
     timeout-minutes: 15
@@ -193,9 +189,6 @@ jobs:
     steps:
       - name: Fix usage of insecure GitHub protocol
         run: sudo git config --system url."https://github".insteadOf "git://github"
-      - name: Fix git protocol for Node 14
-        if: ${{ startsWith(matrix.NODE_VERSION, '14.') }}
-        run: sudo git config --system url."https://github".insteadOf "ssh://git@github"
       - uses: actions/checkout@v2
       - name: Use Node.js ${{ matrix.NODE_VERSION }}
         uses: actions/setup-node@v2
@@ -221,28 +214,28 @@ jobs:
         include:
           - name: PostgreSQL 11, PostGIS 3.0
             POSTGRES_IMAGE: postgis/postgis:11-3.0
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: PostgreSQL 11, PostGIS 3.1
             POSTGRES_IMAGE: postgis/postgis:11-3.1
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: PostgreSQL 11, PostGIS 3.2
             POSTGRES_IMAGE: postgis/postgis:11-3.2
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: PostgreSQL 11, PostGIS 3.3
             POSTGRES_IMAGE: postgis/postgis:11-3.3
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: PostgreSQL 12, PostGIS 3.3
             POSTGRES_IMAGE: postgis/postgis:12-3.3
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: PostgreSQL 13, PostGIS 3.3
             POSTGRES_IMAGE: postgis/postgis:13-3.3
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: PostgreSQL 14, PostGIS 3.3
             POSTGRES_IMAGE: postgis/postgis:14-3.3
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
           - name: PostgreSQL 15, PostGIS 3.3
             POSTGRES_IMAGE: postgis/postgis:15-3.3
-            NODE_VERSION: 19.3.0
+            NODE_VERSION: 18.12.1
       fail-fast: false
     name: ${{ matrix.name }}
     timeout-minutes: 15

2.3.0.md

@@ -0,0 +1,82 @@
+# Upgrading Parse Server to version 2.3.0
+
+Parse Server version 2.3.0 begins using unique indexes to ensure the User's username and email are unique. This is not a backwards incompatible change, but it may in some cases cause a significant performance regression until the index finishes building. Building the unique index before upgrading your Parse Server version will eliminate the performance impact, and is a recommended step before upgrading any app to Parse Server 2.3.0. New apps starting with version 2.3.0 do not need to take any steps before beginning their project.
+
+If you are using MongoDB in Cluster or Replica Set mode, we recommend reading Mongo's [documentation on index building](https://docs.mongodb.com/v3.0/tutorial/build-indexes-on-replica-sets/) first. If you are not using these features, you can execute the following commands from the Mongo shell to build the unique index. You may also want to create a backup first.
+
+```js
+// Select the database that your Parse App uses
+use parse;
+
+// Select the collection your Parse App uses for users. For migrated apps, this probably includes a collectionPrefix.
+var coll = db['your_prefix:_User'];
+
+// You can check if the indexes already exists by running coll.getIndexes()
+coll.getIndexes();
+
+// The indexes you want should look like this. If they already exist, you can skip creating them.
+{
+  "v" : 1,
+  "unique" : true,
+  "key" : {
+    "username" : 1
+  },
+  "name" : "username_1",
+  "ns" : "parse.your_prefix:_User",
+  "background" : true,
+  "sparse" : true
+}
+
+{
+  "v" : 1,
+  "unique" : true,
+  "key" : {
+    "email" : 1
+  },
+  "name" : "email_1",
+  "ns" : "parse.your_prefix:_User",
+  "background" : true,
+  "sparse" : true
+}
+
+// Create the username index.
+// "background: true" is mandatory and avoids downtime while the index builds.
+// "sparse: true" is also mandatory because Parse Server uses sparse indexes.
+coll.ensureIndex({ username: 1 }, { background: true, unique: true, sparse: true });
+
+// Create the email index.
+// "background: true" is still mandatory.
+// "sparse: true" is also mandatory both because Parse Server uses sparse indexes, and because email addresses are not required by the Parse API.
+coll.ensureIndex({ email: 1 }, { background: true, unique: true, sparse: true });
+```
+
+There are some issues you may run into during this process:
+
+## Mongo complains that the index already exists, but with different options
+
+In this case, you will need to remove the incorrect index. If your app relies on the existence of the index in order to be performant, you can create a new index, with "-1" for the direction of the field, so that it counts as different options. Then, drop the conflicting index, and create the unique index.
+
+## There is already non-unique data in the username or email field
+
+This is possible if you have explicitly set some user's emails to null. If this is bogus data, and those null fields should be unset, you can unset the null emails with this command. If your app relies on the difference between null and unset emails, you will need to upgrade your app to treat null and unset emails the same before building the index and upgrading to Parse Server 2.3.0.
+
+```js
+coll.update({ email: { $exists: true, $eq: null } }, { $unset: { email: '' } }, { multi: true })
+```
+
+## There is already non-unique data in the username or email field, and it's not nulls
+
+This is possible due to a race condition in previous versions of Parse Server. If you have this problem, it is unlikely that you have a lot of rows with duplicate data. We recommend you clean up the data manually, by removing or modifying the offending rows.
+
+This command, can be used to find the duplicate data:
+
+```js
+coll.aggregate([
+  {$match: {"username": {"$ne": null}}},
+  {$group: {_id: "$username", uniqueIds: {$addToSet: "$_id"}, count: {$sum: 1}}},
+  {$match: {count: {"$gt": 1}}},
+  {$project: {id: "$uniqueIds", username: "$_id", _id : 0} },
+  {$unwind: "$id" },
+  {$out: '_duplicates'} // Save the list of duplicates to a new, "_duplicates" collection. Remove this line to just output the list.
+], {allowDiskUse:true})
+```