Patching entities: Temporary and permanent IDs

[HappyNomad]

I use JSON Patch for persistent object models where collections are unordered sets rather than lists. It's a common scenario, so let's standardize this specialized behavior. I want to help craft an "Entity JSON Patch" RFC. It would be based on the JSON Patch RFC but with key differences. Collections have no order and are instead indexed by ID.

I described how to use permanent IDs in paths at #12 (comment). As for add or replace operations, the value can be a permanent ID. The applied new value is the existing object indicated by that ID.

In issue #5, @briancavalier "raises the problem of server-assigned ids: how can a client submit a patch to add an item where the object key is supposed to be an id that needs to be assigned by the server?" For add or replace operations that create a new value, the value is of the form "MyNamespace.MyType/$1". This consists of the type of object to create, followed by a / separator, followed by the temporary ID. The temporary ID consists of a "$" followed by a number that's incremented for each new temporary ID. The temporary ID is thereafter used to reference the new object throughout the scope of the patch document transaction. it can be used in the same ways that permanent IDs can be used.

[HappyNomad]

My implementation of these concepts is steadily progressing. I've settled on prefixing permanent IDs with @ for children and ^ for references, temporary IDs with #, and writing new values as temp ID followed by type. Examples are as follows:

• Permanent ID (child): @foo
• Permanent ID (reference): ^foo
• New value (child): #3/Namespace.Type
• Temporary ID (reference): #3

[HappyNomad]

Regarding my progress, I have client-to-server sync working. The client tracks changes and packages them into an "Entity JSON Patch" document, that the server then translates into MongoDB's update syntax. I'm now testing peer-to-peer sync. It involves patching in-memory objects rather than the database. In the process of implementation, I've further clarified the syntax described above:

• End Index
  • Array index at end of add operation's path (child): @
  • Array index at end of add operation's path (reference): ^
• Permanent ID as Index
  • Permanent ID as array index in operation's path (child): @foo
  • Permanent ID as array index at end of remove operation's path (reference): ^foo
• Existing Value
  • Permanent ID as add/replace operation's value (reference): ^foo/Namespace.Type
• New Value
  • New value as add/replace operation's value (child): #3/Namespace.Type
• Temporary ID
  • Temporary ID as array index in operation's path (child): #3
  • Temporary ID as add/replace operation's value (reference): #3

[HappyNomad]

My framework has a website:
https://chainreactive.org/