Db related startup errors after 3.x migration

[asdf01]

Hey Guys

Thanks for all your contributes to parse server.

We have been holding off the migration from 2.x to 3.x and recently had to upgrade from 2.8.4 to 3.10.0 because of aggregation query bugs in 2.x.

After the migration, parse server wouldn't even start. The startup process would stop citing one of the following reasons:

• mongo client couldn't connect to one of the replica set nodes because it couldn't be contacted
• mongodb code couldn't ensure / assert one of the unique indexes. e.g. indexes like username, email, role name.

Replica set node couldn't be contacted
This situation is known to us. Some of the replica set nodes referenced in the mongodb connection url is not available in our test environment. We didn't perceive this to be a problem. It was like a simulation of a situation where some replica set nodes are down due to failure at parse server startup. I would still expect parse server to start in this situation and communicate with the other available nodes. I wasn't sure whether 2.x complained about this, but it certainly didn't stop the server startup for this

Index assertion errors
It complained that the existing index is different to the one being asserted. I didn't investigate further into what specifically was different, but the old 2.x didn't abort server startup for these types of errors.

Looking at the migration docs, it looks like error handling has changed a lot in 3.x. I don't know whether this new startup behaviour was intentional or whether it was an unhandled use case that deviates from the happy path.

I am still not sure whether this promise overhaul was completely necessary. The example given in the migration guide presents this contrived example of how ugly and deeply nested the old 2.x promise chaining was. I don't know how everyone else in the parse server community wrote their code, but our 2.x promising chaining code was very neat:

return Parse.Promise.as().then(() => {
  // construct query and query something
  var query = new Parse.Query("TableName01");
  return query.find({useMasterKey: true});
}).then((queryResults) => {
  // do something with the query results
}).then(() => {
  var promise = new Parse.Promise();
  jsThingThatsNotPromiseBasedButHasACallback(() => {
    //success callback
    promise.resolve()
  }, () => {
    //error call back
    promise.reject();
  })
  return promise;
});

It might be a bit too late to bring this up now, but was neater code the only reason for this 2.x to 3.x overhaul? Hopefully you can see our code was very very neat and easy to understand and maintain.

Has any large scale production site ever successfully upgraded all their production code from 2.x to 3.x?

Thanks again for all your contributions. It's because of people like you guys that people like us have jobs.

[dplewis]

For the index issue follow the 2.3.0 Migration Guide You can simple delete those indexes and they will automatically be added properly on start up or run the provided script.

See Parse.Promise Proposal. Parse.Promise was build off JQuery Deferred model (Deferred promises are deprecated) and aren't A+ complaint as Native Promise. there are a few more reasons in that post. You can read the Parse.Promise to Promise guide if you aren't familiar with native Promises.

The major update from 2 to 3 was to add support for Node 8 features like async / await. Removing the old backbone and response.success/error was a bonus.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[TomWFox]

Closing due to lack of response, feel free to continue the discussion if your issue persists.