Mingle Card: 2703
We have a few of options when we implement this feature:
Make an extra API call for deleted IDs (per lookup)
Modify the API call to include deleted rows (apparently you can't use ALL ROWS soql with REST API, you have to use /services/data/v29.0/queryAll - unfortunately this isn't supported in nforce, so we'd need to roll our own)
we could then either sync all rows to the client or
we could use transport streams to pipe into two streams, once stream containing deleted IDs and one stream containing the active (isDeleted === false) rows
once we have identified the deleted records (Ids or rows) we can either:
if shipping the rows down to the client:
store the deleted row data anyway and simply make the store filter them on each query (using an additional index).
call delete(row.Id) instead of put(row) on the client as we iterate over the returned rows
if shipping the Ids
iterate over the ids calling delete(Id)
Shipping deleted records to the client probably isn't a big deal for the incremental sync case, but we'd almost certainly want to avoid doing that on full syncs.
githubbob42
commented
5 years ago
Mingle Card: 2703 We have a few of options when we implement this feature:
ALL ROWSsoql with REST API, you have to use /services/data/v29.0/queryAll - unfortunately this isn't supported in nforce, so we'd need to roll our own)isDeleted === false) rowsonce we have identified the deleted records (Ids or rows) we can either:
delete(row.Id)instead ofput(row)on the client as we iterate over the returned rowsdelete(Id)Shipping deleted records to the client probably isn't a big deal for the incremental sync case, but we'd almost certainly want to avoid doing that on full syncs.