Agreed, I don’t have answer for this. I propose to drop the optimization for
now given the implementation complexity for any solution that does not cause a
performance degradation.
Adam
> On Feb 11, 2019, at 2:11 PM, Ilya Khlopotov wrote:
>
>> We could represent these using the following set
> We could represent these using the following set of KVs:
>
> (“foo”, “active”) = true
> (“foo”, “owner”) = kCONFLICT
> (“foo”, “owner”, “1-abc”) = “alice”
> (“foo”, “owner”, “1-def”) = “bob”
I still cannot see how we can figure out if conflict for JSON path is present
without reading previous
On 2019/02/11 16:04:45, Adam Kocoloski wrote:
> Thanks Ilya. Some comments:
>
> > - `{NS} / {docid} / _info` = '{"scheme": {scheme_name} / {scheme_revision},
> > "revision": {revision}}'
> > - `{NS} / {docid} / _data / {compressed_json_path} = latest_value | part`
> > - `{NS} / {docid} /
Oh, for sure we can do that. I was just trying to think of a clever
way that replicated edits could also find their edit branch with a
single read as well instead of having to pull out the entire tree.
On Mon, Feb 11, 2019 at 9:04 AM Adam Kocoloski wrote:
>
> Not sure I follow. If a transaction
Hi Paul,
As you know, I try my hardest to post well-researched comments to this
mailing list, and this time I fell short of that. Please accept my
apologies. Let me try and re-frame the problem, and respond to your
criticisms.
My point is: we need more public design discussions and review, and
Not sure I follow. If a transaction needs the full revision tree for a single
document it can retrieve that with a single range read for the (“_meta”, DocID)
prefix.
Adam
> On Feb 8, 2019, at 6:35 PM, Paul Davis wrote:
>
> Ah, that all sounds good. The only thing I'm not initially seeing as
