stale[bot]
commented
3 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Is your feature request related to a problem? Please describe. Need to allow custom ObjectId's to be specified on ParseObject's when creating new objects.
I am (trying to) replicate data between (desktop) client and parse-server. However, due to hurdles keeping the two different databases in line with each other, it would very advantageous if the local record id's matched the server record id's (ObjectId). This would solve a lot of headaches and make syncing far more efficient and do-able. At the moment there is just too many obstacles that makes it almost impossible to achieve. This is a show stopper for me (and I really don't want to re-architect my entire apps stack).
It is easy enough to generate an ObjectId locally that matches the generation technique on the server side, when creating new objects on the local client.
Allowing for custom ObjectId's has been enabled on the server side for a few versions already, with related changes being implemented in some of the other Parse SDK's. However it is lacking in this SDK.
Currently (using the 2.0.0-develop-1 nuget) providing an ObjectId to a new parse Object, fails with an exception (Parse.Infrastructure.ParseFailureException: 'Object not found.') when trying to save the object.
Describe the solution you'd like To be able to provide a custom self generated ObjectId on a new ParseObject instance, which then saves to the server using that provided ObjectId.
Describe alternatives you've considered The require configuration on the server is enabled, and tested using Postman, which does successfully save the object with the provided ObjectId.
Additional context I would happily help if someone points me in the right direction... I am not very familiar with the SDK at all, especially with the changes to the 2.0.0-develop-1 code base, but willing to give it a bash with some help...
It does appear that if a ObjectId is present, then it is using a "PUT" to the api, instead of a "POST" used for a new object. It also then also uses the ObjectId in the api as the path ({url}/class/objectid), whereas when doing a POST with the REST API, you leave the api path without adding the objectid ({url}/class), but add the objectid to the body, and then the object is created on the server with the specified objectid.