Option allowCustomObjectId forces all objects to have custom objectId

[lsmilek1]

New Feature / Enhancement Checklist

• [ x] I am not disclosing a vulnerability.
• [x ] I am not just asking a question.
• [x ] I have searched through existing issues.

Current Limitation

Currently it is not possible to have mixed environment of custom and server generated objectId with allowCustomObjectId = true. At certain database schemes it is desired that some objects have their objectId generated by server and some (mainly in other object class) would get a custom objectId.

Feature / Enhancement Description

• Improve documentation stating clearly that if allowCustomObjectId = true the createdAt is used to decide whether the object is being created or updated. So that developers know how the create/update is handled
• Remove code blocking to create an object where allowCustomObjectId = true fore the objectId to not be nil, for example:

  Parse-SDK-JS/src/ParseObject.js

  Line 2402 in d196e7f

  if (allowCustomObjectId && !el.id) {

Example Use Case

As an example - in my use case there is always one private User object and always one public Profile object. Having the ability to set custom objectId to Profile that is same as the related User.objectId would give a direct reference between these two objects, saving following load:

• back-end fetch and device sync when creating account (2x save reference between User and Profile)
• improve the client code readability as the client code always need to pass around two different objectId for one user, instead of one "device user" objectId
• cloud code triggers have to do extra fetch of the Profile or User object to find related partner (for example to set ACL when there is only profile's objectId known)
• extra field at both Profile or User to link them and for some scenarios also indexing

Alternatives / Workarounds

Currently used workaround is to use reference field in each linked objects, as mentioned above the User.profileId and Profile.userId, but when user A is saving a new message to user B and A knows only B's profiles objectId, the cloud code has to fetch the Profile object to be able to set ACL to the recipient User.objectId. With growing user base and larger message count this is not negligible overload

3rd Party References

• As another use example can be the mstniy's comments here: feat: Allow saving with custom objectId #1309
• ParseSwift SDK: Allow mixed environment of server generated and custom objectId Parse-Swift#220

Additional observations

• As mentioned in JS discussion it force to always use a custom id and the allowCustomObjectId is a confusing name for that. I can confirm that - as a newcomer to Parse I understood that flag for a long time wrong, that I can use both, and learned the hard way the opposite. So either it should be renamed, or the SDKs updated (what I see as small change), plus added in the documentation that allowCustomObjectId will still generate objectId if it is not defined (together with mentioning that createdAt is needed when allowCustomObjectId if true.
• Testing with ParseSwift SDK I found that it works as intended test comit, although I am not sure if JS SDK is more critical as it is used by server directly.

Unfortunately I am very bad in javaScript and would most probably do more harm than profit but with some guidance I can try. Although to run test cases I will certainly fail as I am newcomer knowing only swift and running Parse with back4app... The documentation I can cover!

[github-actions]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[parse-github-assistant]

The label type:feature cannot be used in combination with type:improvement.

[musthafa1996]

Hi @lsmilek1. This PR #1540 resolves the issue.