James M Snell wrote:

Soft-delete is a special case.

Soft delete is a move operation, it's not that special. What's special is the need to be able to move it back, like an OS trashcan. So when I see things like rel="trash", I suspect there's a use-case specific modelling problem stopping a general purpose solution getting out.


With this, entries are moved to a trash
collection.  We need a way of indicating that the entry has been removed
from it's original feed, while at the same time indicating it's new
location in the trash feed, e.g., something along the lines of:

  <x:deleted>
    <id>tag:example.org,2007:foo</id>
    <link rel="trash"
          type="application/atom+xml"
          href="/trash/foo" />
  </x:deleted>

Entries in the trash collection can be undeleted or purged.  If they are
undeleted, they go back to the original feed and are removed from the
trash.  If they are purged, all of the metadata, save the id and perhaps
a timestamp, will be removed from the database.

I can see why you need a way to indicate where the trashed entry should go back to, but not where it went to /from/ the original feed. If you really need that, I suggest you need to generalise it to a moved-from marker. In that case, don't bake the notion of "trash" or "delete" into a design for soft delete - it's a move op. I have other concerns,

- about this kind of metadata becoming accumulated cruft, that requires extra tooling to clean up.

- mixing up the state and housing of an entry with its type (a tombstone is a thing, but the person underneath it is surely dead).



7) one way (master-replica) full and incremental sync.

This is a significant use case for us.  We must have a reliable and
performant one-way sync model that can support full and incremental
operation.  By incremental I mean we need to have the ability to request
a feed listing only changes that have occurred since the previous sync
operation.

We've been here before. You can't do this without a timestamp (or some temporal ordering) that everyone agrees on (where 'everyone' is all the clients using the server).

cheers
Bill

Reply via email to