Thanks, Mike.
I know Jan has something to say on this topic, but please note he is on
vacation through this week and may need to be nudged to post here once
he returns ;)
-Joan
On 2019-10-07 5:34 a.m., Mike Rhodes wrote:
All,
I think my email wasn't my clearest missive ever, so likely pretty easy to get
lost in it :)
I think my idea to include the read version in the document rev ID is likely a
bad one. But, if we are already including it in the database seq value, and
we've done the work to make that number transfer cleanly across FDB instances,
there's probably some interesting API directions post 4.0 where we make more
use of that value towards more efficient RYW at a database level.
I'm beginning to get the feeling of what this API might look like and avoid
being painful/confusing. For example, given the more advanced nature of these
APIs, I'd see them operating at the HTTP header level, where we can provide
request and response headers with the same name to support sending/receiving
database seq values across ~all read/write requests.
Taking Joan and Adam's points on board, my view is that we semi-shelve this
discussion to enable focus on getting 4.0 out the door. But, I think we can
start to introduce useful functionality based on this during the 4.x series if
we're careful (i.e., avoiding breaking changes). Of course, we should probably
step back to user pain points first as Joan implies, otherwise we're building
for the sake of building and the opportunity cost is not negligible.
I think we might also want to hash out the "interchangable backend" question a
bit more. As Adam says, FDB gives us a number of features that would be hard to replicate
on different backends -- at least in the clustered case -- so nailing down a position
there sounds important.
