> Come on Blake, you have all been developing software long enough to know > that "there's nothing about Accord that prevents this" is close to > meaningless. > > If it's so easy to address an overwhelmingly popular use case, then let's > add it to the initial work.
This is moving the goal posts. The concern I was addressing implied this wasn’t possible with Accord and asked if we should prefer “a design that allows local serialization with EC between regions”. Accord is a design that allows this, and support for it is an implementation detail. Whether or not it’s in scope for the initial work is a project planning discussion, not a transaction management protocol tradeoff discussion. > I think this is the crux of our disagreement, I very much want to avoid a > future where we have to maintain two separate consensus systems. I want to avoid it also, but if we’re going to compare Accord against a hypothetical SQL feature that seems to lack design goals, or any clear ideas about how it might be implemented, I don’t think we can rule it out. > On Oct 11, 2021, at 6:02 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > > On Sat, Oct 9, 2021 at 11:23 PM Blake Eggleston > <beggles...@apple.com.invalid <mailto:beggles...@apple.com.invalid>> wrote: > >> 1. Is it worth giving up local latencies to get full global consistency? >> Most LWT use cases use >> LOCAL_SERIAL. >> >> This isn’t a tradeoff that needs to be made. There’s nothing about Accord >> that prevents performing consensus in one DC and replicating the writes to >> others. That’s not in scope for the initial work, but there’s no reason it >> couldn’t be handled as a follow on if needed. I agree with Jeff that >> LOCAL_SERIAL and LWTs are not usually done with a full understanding of the >> implications, but there are some valid use cases. For instance, you can >> enable an OLAP service to operate against another DC without impacting the >> primary, assuming the service can tolerate inconsistency for data written >> since the last repair, and there are some others. >> > > Come on Blake, you have all been developing software long enough to know > that "there's nothing about Accord that prevents this" is close to > meaningless. > > If it's so easy to address an overwhelmingly popular use case, then let's > add it to the initial work. > > 2. Is it worth giving up the possibility of SQL support, to get the >> benefits of deterministic transaction design? >> >> This is a false dilemma. Today, we’re proposing a deterministic >> transaction design that addresses some very common user pain points. SQL >> addresses different user pain point. If someone wants to add an sql >> implementation in the future they can a) build it on top of accord b) >> extend or improve accord or c) implement a separate system. The right >> choice will depend on their goals, but accord won’t prevent work on it, the >> same way the original lwt design isn’t preventing work on multi-partition >> transactions. In the worst case, if the goals of a hypothetical sql project >> are different enough to make them incompatible with accord, I don’t see any >> reason why we couldn’t have 2 separate consensus systems, so long as people >> are willing to maintain them and the use cases and available technologies >> justify it. >> > > I think this is the crux of our disagreement, I very much want to avoid a > future where we have to maintain two separate consensus systems.
