You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Patching entities: Temporary and permanent IDs #20
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.
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:
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
Activity
HappyNomad commentedon Apr 1, 2018
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:@foo^foo#3/Namespace.Type#3HappyNomad commentedon Jan 10, 2019
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:
@^@foo^foo^foo/Namespace.Type#3/Namespace.Type#3#3HappyNomad commentedon Feb 27, 2019
My framework has a website:
https://chainreactive.org/