RestWrite installation handling issue

[stephentuso]

This may only apply to Android, I haven't used parse server with iOS yet.

I don't think there is anything wrong with my setup, and I'm saving the installation with ParseInstallation.getCurrentInstallation().saveInBackground(). I wouldn't be too surprised if this is due to something I'm doing wrong, but here's what's happening:

If I clear the app's data (or reinstall it), the deviceToken on the new installation object is not set, and the old installation object is still there.

In #422 it was mentioned that the deviceToken is updated after the installation has already been saved. After looking at RestWrite and logging the requests I think I've found the problem.

Here's what's included in the request to add the deviceToken:

Query: {
    "objectId": "abcdefghijk"
}
Data: {
    "pushType": "gcm",
    "deviceToken": "abcd1234...",
    "objectId": "abcdefghijk"
}

Here's what's I'm 99% sure is happening in RestWrite (starting at line 575):

1. Because the query and objectId aren't null, the first promise block (which just checks for errors) is executed.
2. No installation matches are found because installationId is not included.
3. The device token matches that of the original installation
4. Because there are no installation matches, at least one device token match, and data.installationId is null (see the statements leading up to line 639), the original installation's objectId is returned
5. The deviceToken is just set on the original installation.

This is only happening because deviceToken hasn't changed, so if a new gcm token was requested on the first app launch (I seem to remember being able to do that) that might fix it, but then you're left with unneeded installations in the database.

If objectId is queried and matched, shouldn't it be treated the same as a match on installationId? Doing so should result in the correct path, because this is what would happen if installationId was included in the request data:

1. Error checking block would execute
2. The new installation would be matched by the included installationId
3. The old installation would match the deviceToken
4. Because the included deviceToken isn't null and doesn't match the installationMatch deviceToken (line 678), the old installation would be deleted, and the deviceToken would be set on the new installation.

I'll submit a pull request with a possible quick fix in a few minutes.

[gfosco]

Merged #673, this should be fixed in 2.1.4.