It seems likely (although not yet certain) that in the future we will end up wanting loosely-defined relationships between collections. For example, we might want to add a new "containers" collection which holds all the Firefox containers defined by a user, and the history collection might want to refer to what container a visit relates to.
If the existing batch mechanism could be extended such that the same batch ID can be used for multiple collections, it would mean that clients can ensure that the data uploaded across collections is always consistent. There are probably no changes needed to the API itself, just to the semantics of when the various batch query params are valid.
This is a little vague and something we don't need now. To be honest we aren't even 100% sure we will need it in the future (and our current plans mean we almost certainly will not need it over the next few months), but I thought I'd get this on the radar anyway. cc @rfk, @thomcc
tublitzed
commented
4 years ago
It seems likely (although not yet certain) that in the future we will end up wanting loosely-defined relationships between collections. For example, we might want to add a new "containers" collection which holds all the Firefox containers defined by a user, and the history collection might want to refer to what container a visit relates to.
If the existing batch mechanism could be extended such that the same batch ID can be used for multiple collections, it would mean that clients can ensure that the data uploaded across collections is always consistent. There are probably no changes needed to the API itself, just to the semantics of when the various batch query params are valid.
This is a little vague and something we don't need now. To be honest we aren't even 100% sure we will need it in the future (and our current plans mean we almost certainly will not need it over the next few months), but I thought I'd get this on the radar anyway. cc @rfk, @thomcc