Considering the common use cases of blobs, and that they will always be used when related to from a different application document, then the following restrictions might be reasonable:
blob_v1 and blob_piece_v1 documents are single writer
blob_v1 and blob_piece_v1 can't be UPDATED
We could possibly even go so far as to say neither document need be DELETED either, as this is something we can simply infer from the presence (or absence) of a "parent" document. This could be considered separately though as it can also be implemented without other restrictions on blob.
Doing this would exclude any of the "fun" manipulations of blobs we imagined (in place swapping/adding pieces). What it would give us is a simplified pattern for materializing blobs (no longer multiple views for one blob).
An argument against is that actually we, kind of by default, have update capabilities for blobs, it's there in the current implementation. I wonder if we actually need it though, and if there are benefits to removing it :thinking:
Considering the common use cases of blobs, and that they will always be used when related to from a different application document, then the following restrictions might be reasonable:
blob_v1andblob_piece_v1documents are single writerblob_v1andblob_piece_v1can't beUPDATEDWe could possibly even go so far as to say neither document need be
DELETEDeither, as this is something we can simply infer from the presence (or absence) of a "parent" document. This could be considered separately though as it can also be implemented without other restrictions on blob.Doing this would exclude any of the "fun" manipulations of blobs we imagined (in place swapping/adding pieces). What it would give us is a simplified pattern for materializing blobs (no longer multiple views for one blob).
An argument against is that actually we, kind of by default, have update capabilities for blobs, it's there in the current implementation. I wonder if we actually need it though, and if there are benefits to removing it :thinking: