Removed and moved.

[meteormanaged]

I'm having difficulty understanding the information being presented to me. Not sure if it's a bug, if it's happening in the wrong order, or if I'm just missing something completely.

6 items are indexed in the initial "update" when the livequery is initialized. data is retained in a variable so we may reference it's index to understand what was removed.

{ removed: [ { _index: 6 } ],
  moved:
   [ { old_index: 2, new_index: 1 },
     { old_index: 3, new_index: 2 },
     { old_index: 4, new_index: 3 },
     { old_index: 5, new_index: 4 },
     { old_index: 6, new_index: 5 } ],
  copied: null,
  added: null }

When we receive an update,it tells me that index 6 was removed. If we review the "moved" section, we see that actually it was index 1 that was pulled, and now indexes have been updated.

The result is there is now no longer an index 6, but that wasn't the index that was removed. Removing any single index from the database would return the same "removed" index in the results passed back.

Given the information provided to me at the outset, and then on update: (diff, data)

If I look at diff.removed, the data is not useful or relevant to the update, even compared to the reference data from last update.

If I look at diff.moved, i could sort through the reference data and determine what values exist in _index, and then gather the values of each object's old_index property, and the compare and determine what was removed.

If I look at data, I could take my reference data and compare object properties (but not entire objects, as the _index value has now changed) to attempt to determine which has no match and must have been removed.

All of these seem to be quite the work out. Could simply be included as such:

Removed should tell you what was removed. Moved should tell you what was moved. Data should be the new data.