Both custom and generated objectId in one project

Client SDKs ParseSwift SDK
#1

I tried to save an object with no custom objectId"

Invite inbox save failed: Inbox ({“rid”:“8AA2pyT7WN”,“d”:“zG65F…TM”,“s”:“6yQCNQ4Kxo”,“ACL”:{“OZZUF3G8L2”:{“write”:true,“read”:true},“8AA2pyT7WN”:{“write”:true,“read”:true}}})

and I receive an error related to these lines:

As I was learning to use Parse so far with only device user objects that has a defined Id - User and Profile objects have same objectId - so I use allowCustomObjectId = true. Therefore I never noticed before that it is not possible to combine both custom and server generated objectId behaviour until now when I tried to save another object Inbox that should get the objectId assigned.

I was thinking that if the object does not exist in database and I do not specify an objectId then the save function will assign some to it. Please, confirm, that it is not possible to use both, so that I would switch all objects to automatic objectId. Otherwise I think it could be just SDK blocking that save operation?

Thank you

#2

It is not recommended to do both as the Swift SDK nor any of the other client SDK’s support it. You should either:

  1. Let the server generate 100% of the objectId’s
  2. Generate 100% of the objectId’s on the client with customObjectIds enabled and then save

The server does support a mixed environment, but my guess is this done when using different clients, Swift SDK generating own objectIds, Android SDK doesn’t generate own objectIds. Another scenario is supporting multiple versions of a particular SDK

1 Like
#3

I see. Took me some time to find this out as I somehow assumed it can handle both. It is not a big deal, rather than mixing two SDK versions I will redo few steps back and add only one field to ParseUser object to hold Profile objectId. It’s just that knowing the profile objectId would spare few queries in the cloud code.

Thank you for a prompt answer!

Just out of curiosity, the SDKs does not support it “yet” or is it not being considered for some vulnerability reasons?

#4

I’m not sure, it’s not something I personally see needs implementation. This type of thing seems like something the developer should handle via cloud code. Meaning, the client acts as one way and the cloud code accounts for the mixed environment.