Breaking out forum topic 314 into separate posts for each proposed Op.
Delete
The delete op is used to remove recs from the Haystack Server.
Request (by filter): a grid with a single row and following columns:
filter: required Str encoding of filter
Request (by id): a grid of one or more rows and one column:
id: a Ref identifier
Response: grid with a row for each entity removed. If a filter read and no matches were found this will be an empty grid with no rows. If a read by id, then each row corresponds to the request grid and its respective row ordering. If an id from the request was not found, the response includes a row of all null cells.
Example of filter read request:
ver:"2.0"
filter
"point and siteRef==@siteA"
Example of read by id with three identifiers:
ver:"2.0"
id
@vav101.zoneTemp
@vav102.zoneTemp
@vav103.zoneTemp
Example of a read response where an id is not found:
How should we handle the possibility of removing a referenced rec? i.e. a site is removed that has equip and point records the reference that site.
Mark OellermannTue 6 Oct 2015
Hi Shawn, Thanks for this. In response to your question above, because of the generous use of siteRef and equipRef, and the number of other types of refTag, I think a cascading delete will be of limited use, and will likely just catch people out when more entities are deleted than the caller expects.
So I'd suggest short of leaving broken refs (not good), the best option may be to remove the ref tags on the referring entities. This does mean that if you delete a site without first removing it's equip entities first you'll have a situation where the equip entities are left hanging (and strictly not following the haystack convention), but this approach simply means the onus is on the caller to call the deletions in the right order, just as it is for creation. Mark
Shawn Jacobson Tue 8 Sep 2015
Breaking out forum topic 314 into separate posts for each proposed Op.
Delete
The delete op is used to remove recs from the Haystack Server.
Request (by filter): a grid with a single row and following columns:
Request (by id): a grid of one or more rows and one column:
Response: grid with a row for each entity removed. If a filter read and no matches were found this will be an empty grid with no rows. If a read by id, then each row corresponds to the request grid and its respective row ordering. If an id from the request was not found, the response includes a row of all null cells.
Example of filter read request:
Example of read by id with three identifiers:
Example of a read response where an id is not found:
Questions:
Mark Oellermann Tue 6 Oct 2015
Hi Shawn, Thanks for this. In response to your question above, because of the generous use of siteRef and equipRef, and the number of other types of refTag, I think a cascading delete will be of limited use, and will likely just catch people out when more entities are deleted than the caller expects.
So I'd suggest short of leaving broken refs (not good), the best option may be to remove the ref tags on the referring entities. This does mean that if you delete a site without first removing it's equip entities first you'll have a situation where the equip entities are left hanging (and strictly not following the haystack convention), but this approach simply means the onus is on the caller to call the deletions in the right order, just as it is for creation. Mark