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
Managing a bidirectional relationship on both ends could leave data in an inconsistent state
Mongodb doesn't offer any transactional semantics, the update might succeed on the first document and fail on the second one
Here is an example, let's say you want to change an article's 'author' relationship (targets people resource)
In our case this is bidirectional and the people resource also has an 'articles' relationship, so you also need to reflect that the current author no longer has a relation to the article in question
you could start out by updating the articles 'author' rel, but run into a failure while updating the people 'articles' rel, conversively you could start by updating the people 'articles' rel, but run into a failure while updating the articles 'author' rel
Harvester eliminates the risk by exposing an 'inverse' link attribute, this attribute informs Harvester that the relationship is actually being managed on the other side of the relationship
The link can now be updated with 1 atomic operation to reflect the change on both ends
The managed side of the relationship outputs linkage objects with the ids, as well as 'related' and 'self' links, the non-managed side of the relationship outputs 'related' and 'self' links only
Pro tip: Model the resource so that ids are managed on the one-side, not on the many-side, this is more efficient as less data has to be transferred when retrieving / updating a resource
Important : The inclusion mechanism materialises the link so that a full data graph can be resolved as part of a compound document
Given the following resource url : /articles?include=comments
the comments link object is transformed with the addition of linkage objects, the object ids can subsequently be used to match the included comments resource data
Managing a bidirectional relationship on both ends could leave data in an inconsistent state
Mongodb doesn't offer any transactional semantics, the update might succeed on the first document and fail on the second one
Here is an example, let's say you want to change an article's 'author' relationship (targets people resource)
In our case this is bidirectional and the people resource also has an 'articles' relationship, so you also need to reflect that the current author no longer has a relation to the article in question
you could start out by updating the articles 'author' rel, but run into a failure while updating the people 'articles' rel, conversively you could start by updating the people 'articles' rel, but run into a failure while updating the articles 'author' rel
Harvester eliminates the risk by exposing an 'inverse' link attribute, this attribute informs Harvester that the relationship is actually being managed on the other side of the relationship
The link can now be updated with 1 atomic operation to reflect the change on both ends
The managed side of the relationship outputs linkage objects with the ids, as well as 'related' and 'self' links, the non-managed side of the relationship outputs 'related' and 'self' links only
Pro tip: Model the resource so that ids are managed on the one-side, not on the many-side, this is more efficient as less data has to be transferred when retrieving / updating a resource
Important : The inclusion mechanism materialises the link so that a full data graph can be resolved as part of a compound document
Given the following resource url : /articles?include=comments
the comments link object is transformed with the addition of linkage objects, the object ids can subsequently be used to match the included comments resource data
The text was updated successfully, but these errors were encountered: