Hi,
We’d expand each document into a series of key-value pairs, where the key is
the full path into the object and the value is the scalar value. E.g,
{“foo”: 12, “bar”, {“baz”: 13}}
Would be
foo => 12
bar.baz => 13
With some suitable prefix to denote database name and document id. If the 10k
limit on the full path is a problem in practice we can use the same trick as
FoundationDB’s “Directory Layer”, where another part of the fdb keyspace serves
to alias very long strings to very short ones. It would be nicer not to, for
simplicity’s sake, but when we get deeper into the trade-off discussion we can
see how practical the 10k limit would be before innovating further.
Scalar values larger than 100k should be rare but if we want to support them
would be achieved by splitting the value across multiple keys with a numeric
index at the end of key. This is approach we will have to take for attachments
(and, in fact, it’s how attachments are stored today, as a series of small
chunks).
B.
> On 24 Jan 2019, at 00:17, ermouth <ermo...@gmail.com> wrote:
>
> Hi, Robert
>
>> as something we don’t know how to carry over yet
>
> Is there any workaround for FDB limitations for key size (10kb) and value
> size (100kb)?
>
> ermouth
