# Data model without support for per key revisions
In this model "per key revisions" support was sacrificed so we can avoid doing
read of previous revision of the document when we write new version of it.
# Ranges used in the model
- `{NS} / _mapping / _last_field_id
- `{NS} / _mapping /
Ah, that all sounds good. The only thing I'm not initially seeing as
obvious is how we lookup a revision path to extend during replication
when the previous revision may be anywhere in the list of $revs_limit
revisions. Feels like there might be some sort of trickery to do that
efficiently.
Thanks for taking the 2.3.1 release, Jan! I've added a couple of
additional suggested commits on the 1908 comment thread.
-Joan
- Original Message -
> From: "Jan Lehnardt"
> To: "CouchDB Developers"
> Sent: Thursday, February 7, 2019 10:41:49 AM
> Subject: [DISCUSS] Release 2.3.1
>
>
Adam asked one question on our dev IRC that I wanted to be sure
made it into this thread:
"It's not totally clear to me - is the RFC supposed to encourage a
discussion about _what_ gets built, or _how_ it gets built?"
Jan responded:
"It is meant to let the project get in on early design
Totally unacceptable! ;) In fact some key bits of that model got dispersed
into at least two separate emails so you’re likely not the only one. I’ll
restate here:
The size limits in FoundationDB preclude us from storing the entire key tree as
a single value; in pathological situations the
Heya Adam, thanks for re-focussing this. All I meant to say: let’s get your
initial proposal implemented with the constraints you mention and take it from
there, not make it even simpler than that.
Best
Jan
—
> On 8. Feb 2019, at 04:35, Adam Kocoloski wrote:
>
> Bob, Garren, Jan - heard you
Agreed, that’s a good fit and is clearly related to the kinds of work FDB is
doing with its simulator. If you watch Wil WIlson’s presentations on the topic
he calls out property-based testing as one isolated example of the broader
theme that he’s trying to drive here.
Adam
> On Feb 8, 2019,
On Thu, Feb 7, 2019 at 9:35 PM Adam Kocoloski wrote:
>
> Bob, Garren, Jan - heard you loud and clear, K.I.S.S. I do think it’s a bit
> “simplistic" to exclusively choose simplicity over performance and storage
> density. We’re (re)building a database here, one that has some users with
> pretty
> I’m relatively happy with the revision history data model at this point.
I forgot to make a note, but which of the various models are you
referring to by "revision history data model". There's been so many
without firm names that my brain is having a hard time parsing that
one.
On Thu, Feb 7,
Hi Adam,
I don't think any of us mean "simple" at the expense of all other factors, but
I'm certainly reacting to what seem to be premature embellishments and
optimizations. I agree with you (of course) that our plans must account for
foundationdb's architecture and best practices, and this
Cheers to that Garren!
Whatever we decide on for the data model I'd like to see a fairly
extensive property based test suite around it. I almost said for
anything above chunked based storage but even for that I'd think that
I'd still want property testing around various keys and tree
mutations.
11 matches
Mail list logo
