Removing row documents when removing row?

[winged]

During implementation of #935, the question came up on how we should deal with row documents when removing them from a table.

Currently, we detach the row documents by removing the corresponding AnswerDocument entry, and setting the row document's family to itself. This makes it an independent document that could also be used by itself in some other context. However, if the frontend is not careful, we could lose track this row document and create dead database entries.

Alternatively, we could delete the document as soon as it's not part of a table answer any more (Careful: Moving a document between tables, which nobody currently does, would thus require adding the document to the destination first, then removing it from the origin table to avoid deletion) - or we implement a specific "Move" mutation for this exact use case if and when we actually need it.

What does not work is having a generic cleanup job, as we don't know the actual application's semantics: A row document could just as well be a top level document in some other context, for example

[czosel]

Thanks for the detailed write-up! :+1: I'm leaning towards removing them after checking that they are not referenced anywhere else. cc @kaldras @anehx

[winged]

Update from some more off-line elaboration:

We probably should move away from creating a document, followed by adding it to the table. When #935 is landed, we could also go towards a CreateRowMutation that implicitly creates the row document, and a DeleteRowMutation to remove the row again. This implies that we won't have any dangling row documents anymore, as the mutation would imply deletion of the row document.

Right now, we (accidentally) left the semantics too open, allowing more behaviour in the implementations than intended.