From ca7f5e8cce25a2fe6e1261d94bcec9fbb4dff80c Mon Sep 17 00:00:00 2001 From: Tobias Schottdorf Date: Thu, 21 Apr 2016 17:54:06 -0400 Subject: [PATCH] Add comment by @bdarnell on WriteBatch compatibility --- docs/RFCS/leader_evaluated_raft.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/RFCS/leader_evaluated_raft.md b/docs/RFCS/leader_evaluated_raft.md index 673b71c3b5d4..dda77415621a 100644 --- a/docs/RFCS/leader_evaluated_raft.md +++ b/docs/RFCS/leader_evaluated_raft.md @@ -361,7 +361,14 @@ Tackle the following in parallel (and roughly in that order): * flesh out the WriteBatch encoding. Ideally, this includes a parser in Go (to avoid an obstruction to switching storage engines), but the critical part here for the purpose of this RFC is hooking up the `RocksDB`-specific - implementation. + implementation and guarding against upstream changes. + We can trust RocksDB to be backwards-compatible in any changes they make, but + we require bidirectional compatibility. We create a batch on the leader and + ship it off to the follower to be applied, and the follower might be running + either an older or a newer version of the code. If they add a new record + type, we either need to be able to guarantee that the new record types won't + be used in our case, or translate them back to something the old version can + understand. * introduce and implement the `Batch` interface. This could be done after the `WriteBatch` encoding is done or, if required to unblock the implementation of this RFC, start with a less performant version based on an auxiliary map