2.3.0.md

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 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.

// 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.

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:

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})