remove `id` from object after destroying it

[vince1995]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest versions of Parse Server and the Parse JS SDK.

Issue Description

I've noticed that when you destroy an object, it still has the id property.

Steps to reproduce

const obj = new Parse.Object("randomCollection");
await obj.save();
console.log(obj.id) // the id
await obj.destroy();
console.log(obj.id); // look at actual/expected outcome

Actual Outcome

console.log(obj.id) // the id

Expected Outcome

console.log(obj.id) // undefined

Environment

Server

• Parse Server version: 4.10.6
• Operating system: Ubuntu 20.04
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): local

Database

• System (MongoDB or Postgres): MongoDB
• Database version: 5.0.3
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): local

Client

• Parse JS SDK version: 3.4.1

Logs

[parse-github-assistant]

Thanks for opening this issue!

• 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

[mtrezza]

Can't follow your steps to reproduce. You are logging the obj ID after saving and before destroying. Why do you expect it be undefined?

[vince1995]

Because the object doesn't persist on the database anymore. So there's no record for this ID. So, why should the ID not be undefined?

[mtrezza]

I think you have left out the last step in steps to reproduce and added it instead to the "expected / actual outcome". Could you rewrite your example to make clear where you are expecting which outcome?

[vince1995]

Ah, yeah, sure. That wasn't clear.

[mtrezza]

I think I understand the issue description now. Could you explain why you expect id to be undefined? The object ID is vaguely indicative of the object state. If it's undefined it could also mean that the object has never been saved.

[vince1995]

Yeah, that's the point. In my opinien if it's undefined, it never persisted in the database or was deleted. But if the object ID is not undefined that should mean that this object has a record in the database.

So here's my question again: When an object is not in the database anymore, why should it have an object ID?

[mtrezza]

So here's my question again: When an object is not in the database anymore, why should it have an object ID?

There are several aspects to consider:

• Inference
  The docs say:

  objectId is a unique identifier for each saved object.

  That doesn't imply that the ID should be deleted after an object das been removed from the DB.
  In fact, none of the fields is unset after an object has been destroyed, see createdAt, updatedAt.

• Internal logic
  Does the ID have to be removed in order for the SDK to work properly?
  There may be internal logic in the Parse SDK or Parse Server that infers an object state from the presence of the ID field. If that was the case, this should be reviewed as a bug.

  For example this does not work:

  await obj.save(null, { useMasterKey: true});
  await obj.destroy();
  obj.unset("objectId");
  await obj.save(null, { useMasterKey: true}); // throws error "Object not found.", probably tries to update an object with the given ID
  

  Maybe it should be possible to easily save, delete and re-save an object, and assigning a new ID if custom obj ID is disabled.

• Developer expectation
  Do other Parse SDKs (or maybe even 3rd party SDKs) usually unset the object ID and is the Parse JS SDK an exception?