On Thu, Aug 25, 2011 at 7:35 PM, Chris Anderson <jch...@apache.org> wrote:
> On Thu, Aug 25, 2011 at 4:06 PM, Paul Davis <paul.joseph.da...@gmail.com>
> wrote:
>> On Thu, Aug 25, 2011 at 6:03 PM, Chris Anderson <jch...@apache.org> wrote:
>>> MVCC semantics would be helpful for the _security object.
>>>
>>> If caching + aliasing it to _local/security is the easier way to add
>>> this, then I think it is OK.
>>>
>>> OTOH it would probably be simple to add a basic (local docs) rev check
>>> to the security updater.
>>>
>>> I am not sure why are talking about a rev tree for local docs, as they
>>> don't replicate, so where would conflicts come from?
>>>
>>
>> Syncing across a cluster.
>
> So we are talking about redefining _local docs as cluster local
> instead of server/file local?
>
> I haven't spent enough time implementing large cluster Couch to know
> what the best way to handle _local docs is, when you are trying to
> make a cluster look like it has the same security object and
> replication history, etc.
>
> At some point it might be easier if everything is the same (same
> implementation for local docs as regular docs) but from my vantage
> point as an application developer, _local docs are easy to understand
> (they don't replicate).
>
> So as long as we keep the expected single node behavior the same, and
> we don't add complexity, I don't have a strong opinion here.
>
> Chris
>
I wouldn't focus on the _local docs suggestion too much. The easiest
scenario to consider is Adam's original description. The _security
object get's updated while a node is gone. When that _node comes back,
it needs to figure out how to update it's out of date _security
object. That's the easy scenario, but also consider pathological
scenarios where nodes are dropping round-robin or the cluster is in
two halves during a network split.
The obvious fix here is to promote the "almost a doc" behavior into
"really is a doc" behavior so that we can use the same algorithms we
already use for replication to resolve conflicts and have an
eventually consistent _security object.
>>
>>> Chris
>>>
>>> On Wed, Aug 17, 2011 at 12:56 PM, Randall Leeds <randall.le...@gmail.com>
>>> wrote:
>>>> On Wed, Aug 17, 2011 at 08:48, Robert Newson <rnew...@apache.org> wrote:
>>>>
>>>>> No, _local docs shouldn't replicate. The value of MVCC in _local docs
>>>>> is to allow reconciliation in copies of the same database, where
>>>>> redundancy is being added under the covers.
>>>>>
>>>>
>>>> To be clear, _local docs do obey MVCC semantics, but do not keep a rev tree
>>>> and thus do not support merging divergent histories. Multiple versions are
>>>> not kept available even when they're in conflict. They have a _rev and they
>>>> do get rejected with conflicts, you just can't access ?new_edits=false
>>>> style
>>>> merging.
>>>>
>>>> I'm in favor of giving them a full rev tree.
>>>>
>>>>
>>>>>
>>>>> Can you start a separate thread for your _meta proposal? It's a
>>>>> interesting thought but it's out of scope for both threads you've
>>>>> raised it in.
>>>>>
>>>>> B.
>>>>>
>>>>> On 17 August 2011 16:41, Benoit Chesneau <bchesn...@gmail.com> wrote:
>>>>> > On Wednesday, August 17, 2011, Robert Newson <rnew...@apache.org> wrote:
>>>>> >> MVCC for _local docs would be useful for BigCouch for the same reason
>>>>> >> it's useful for _security docs, so your impression of what they are is
>>>>> >> superior to reality.
>>>>> >>
>>>>> >> B.
>>>>> >
>>>>> >
>>>>> > would also simplify the code imo. but do you mean their would also be a
>>>>> way
>>>>> > to even replicate local docs with some options?
>>>>> >
>>>>> > - benoit
>>>>> >>
>>>>> >> On 17 August 2011 16:01, Jason Smith <j...@iriscouch.com> wrote:
>>>>> >>> On Wed, Aug 17, 2011 at 9:51 PM, Adam Kocoloski <kocol...@apache.org>
>>>>> > wrote:
>>>>> >>>>> How do you feel about migrating to a blessed _local/security
>>>>> document?
>>>>> >>>>> Maybe its latest version could be cached in the header for speed?
>>>>> >>>>>
>>>>> >>>>> Pros:
>>>>> >>>>>
>>>>> >>>>> * Couch gets (conceptually) simpler rather than more complex
>>>>> >>>>> * It's versioned, you get full doc semantics
>>>>> >>>>> * It doesn't replicate, but 3rd-party tools can pseudo-replicate it
>>>>> as
>>>>> > needed
>>>>> >>>>> * Design documents can enforce policies: if(doc._id ==
>>>>> _local/security
>>>>> >>>>> && doc.members.length == 0) throw {forbidden:"This database may
>>>>> >>>>> never
>>>>> >>>>> be public"}
>>>>> >>>>>
>>>>> >>>>> Eagerly awaiting a list of cons :)
>>>>> >>>>
>>>>> >>>> The only trouble I have with _local/security is that _local documents
>>>>> > are represented using #doc records instead of #full_doc_info records. As
>>>>> > such, they have no support for MVCC.
>>>>> >>>
>>>>> >>> I did not realize that, so one of the points I made was wrong. FWIW I
>>>>> >>> always assumed _local docs were normal docs, except they are
>>>>> >>> special-cased to neither replicate nor be represented in views.
>>>>> >>>
>>>>> >>> Thanks for the tip!
>>>>> >>>
>>>>> >>> --
>>>>> >>> Iris Couch
>>>>> >>>
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Chris Anderson
>>> http://jchrisa.net
>>> http://couchbase.com
>>>
>>
>
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couchbase.com
>
