> The limitation I was calling out was you can't store two different values
> in the same Key.
> {CouchNS}/{DOCID}/{XXX}
Sorry I was not clear. I used DOC_KEY instead of DOCID in the proposal on
purpose. The format of DOC_KEY is TBD. One option is to have DOC_KEY =
DOCID/REVISIONID.
In this case document might look like
```
{
"foo": 5,
"bar": {
"baz": HUGE_BLOB
}
}
```
```
{DB_DOCS_NS} / {DOCID} / {REVISIONID} / 0:
3: foo
4: bar
5: baz
{DB_DOCS_NS} / {DOCID} / {REVISIONID} / 3:
5
{DB_DOCS_NS} / {DOCID} / {REVISIONID} / 4 / 5 | 0: # `|` is used to solve
problem Adam identified
"first 100K"
{DB_DOCS_NS} / {DOCID} / {REVISIONID} / 4 / 5 | 1:
"second 100K"
```
Does it make sense?
Again the format of DOC_KEY is TBD. We might need a level of indirection (which
is unlikely) if we would have to split CouchDB operation into multiple
FoundationDB transactions. We would need it if we want to allow documents
bigger than 10Mb which we shouldn't IMO.
Best regards,
iilyak
On 2019/01/30 19:58:58, Michael Fair <mich...@daclubhouse.net> wrote:
> On Wed, Jan 30, 2019 at 11:54 AM Ilya Khlopotov <iil...@apache.org> wrote:
>
> > Hi Mike,
> >
> > > The trivial fix is to use DOCID/REVISIONID as DOC_KEY.
> > This doesn't solve the issue with scalar values being over the limits
> > FoundationDB can support.
> >
> >
> Right, that wasn't the limitation I was calling out.
>
> The limitation I was calling out was you can't store two different values
> in the same Key.
> {CouchNS}/{DOCID}/{XXX}
>
> Ever revision has the same {CouchNS}/{DOCID}/{XXX} keys but different
> values.
> Making revisions and conflicts a seemingly unavoidable part of the
> discussion to me.
>
