[OPENIDM-14511] _refResourceRev missing from VertexEdge link expaned data. Created: 20/Mar/20 Updated: 20/Mar/20 Resolved: 20/Mar/20 |
|
Status: | Resolved |
Project: | OpenIDM |
Component/s: | Module - Relationships |
Affects Version/s: | 7.0.0 |
Fix Version/s: | 7.0.0 |
Type: | Bug | Priority: | Major |
Reporter: | jason vincent | Assignee: | Dirk Hogan |
Resolution: | Not a defect | Votes: | 0 |
Labels: | clark | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
The _refResourceRev field is missing from VertexEdge Responses. For example: A query like the following should return a `_refResourceRev` field that holds the revision of the role object.
http://localhost:8080/openidm/managed/user?_pageSize=1000&_fields=roles/*&_queryFilter=_id eq 'id1a'
{ "result": [ { "_id": "id1a", "_rev": "2", "roles": [ { "_ref": "managed/role/testrolea", "_refResourceCollection": "managed/role", "_refResourceId": "testrolea", "_refProperties": { "_id": "b9d3beb6-926b-4e27-b4eb-143499ec2690", "_rev": "0", "_grantType": "conditional" }, "name": "testrolea", "description": "testrole1", "condition": "/userName sw \"user1\"", "_id": "testrolea", "_rev": "1", "privileges": [] } ] } ], "resultCount": 1, "pagedResultsCookie": null, "totalPagedResultsPolicy": "NONE", "totalPagedResults": -1, "remainingPagedResults": -1 } (just FYI - `_refProperties/_rev` is the revision of the relationship, and not that of the referenced object). Note that if a EdgeVertex request is made, the `_refResourceRev` field is properly returned.
http://localhost:8080/openidm/managed/user/id1a/roles?_pageSize=1000&_fields=*&_queryFilter=true
{ "result": [ { "_id": "b9d3beb6-926b-4e27-b4eb-143499ec2690", "_rev": "0", "_refResourceCollection": "managed/role", "_ref": "managed/role/testrolea", "_refResourceId": "testrolea", "_refResourceRev": "1", "name": "testrolea", "description": "testrole1", "condition": "/userName sw \"user1\"", "privileges": [], "_refProperties": { "_grantType": "conditional", "_id": "b9d3beb6-926b-4e27-b4eb-143499ec2690", "_rev": "0" } } ], "resultCount": 1, "pagedResultsCookie": null, "totalPagedResultsPolicy": "NONE", "totalPagedResults": -1, "remainingPagedResults": -1 } |
Comments |
Comment by jason vincent [ 20/Mar/20 ] |
_refResourceRev was added to the response of the EdgeVertex responses because there was a conflict between returning the _id and _rev of the relationship and that of the referenced vertex object. When building the response, the JSON of the relationship is treated as primary content and then merged with the content of the referenced vertex, minus the _id and _rev. In the EdgeVertex responses, the _refResourceId and _refResourceRev hold the _id and_rev of the referenced vertex and thus leaves _id and _rev in the response to refer to the relationship object state. In the example note that the _id in the EdgeVertex response is the UUID belonging to the relationship object. In the VertexEdge response, the referenced vertex JSON is considered the primary JSON and then the relationship content is merged with it. Thus the _id and _rev of this response belongs to the vertex. The _id and _rev of the relationship are provided in the _refProperties field. There is therefore no need to add the _refResourceRev in the VertexEdge responses. FYI - In EdgeVertex responses, the _refResourceRev is only returned if the referenced vertex of the relationship is link expanded. |