Description
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 = truethecreatedAtis 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 = truefore theobjectIdto not be nil, for example:Parse-SDK-JS/src/ParseObject.js
Line 2402 in d196e7f
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
UserandProfile) - 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
ProfileorUserobject to find related partner (for example to set ACL when there is only profile'sobjectIdknown) - 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
allowCustomObjectIdis 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!