Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.212.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAL6JQjsPMVB3TzMuh9ntu1pjYbAPcF5L2o6fEeLzjhz5ffa-Q@mail.gmail.com>
References: <111A4F0F-6055-435B-8FF9-8D48CC058E4D@apache.org>
 <CAN-3CBLe1Moe0ot_hyyrh1ydFowdmTmDz80UkOAfKNcgNhTeRw@mail.gmail.com>
 <F7EB94AD-E664-4221-93F1-F123E40A6D6F@apache.org>
 <CAN-3CBJ__jyS7rqdUOPjtL+0czFcfsfLX_3JbJrjJt6n1cUmMQ@mail.gmail.com>
 <CABvT1DFdrNVKv43Y1KKH-0p+AzK35z-Zh_M81BAK0mRfbsQq-g@mail.gmail.com>
 <CAJNb-9q=R6rv-VaY-auxEr38E8kT1wLoGoPHNjE6UUkkNFDMjQ@mail.gmail.com>
 <CABvT1DFLxnESJR7YSXpR6vEuwF-nsOD14BacWt11JzJXDeEbOg@mail.gmail.com>
 <CAAL6JQiYkRrryo9Os2JE1Wrzx5D5TkO2tv76MmLkgJzQakGTWQ@mail.gmail.com>
 <CAEyAqDvf=hTAW3FNsjUQQWppX2jHuZSN52rgB=LoEwc+uMnvyg@mail.gmail.com>
 <CAJ_m3YCisGaHa2PpJ4oTD6XMRmM3dJ+vqsMfFtH_zaObEXJRnw@mail.gmail.com>
 <CAEyAqDue1=4tq13CM535_q+2zpXmqK8KC_AFqKETvag6a4GqMw@mail.gmail.com>
 <CAJ_m3YA+4F7MiecX-pCEgVSJ-642LMOy-eC7avhzoHc8hp3img@mail.gmail.com>
 <CAN-3CBK3_8S=J=gMBDpBGKwj+Gyv6bt55pcicKaU3dMugeOZcg@mail.gmail.com>
 <CAEyAqDv+W-987N790JOLb=dNW1UpPeN2aeRFeG10qsOhjPQXEg@mail.gmail.com>
 <CAAL6JQiSut=WWYS_vHvpvcOefAPhrgmvbd+SFpuJfcxf9nhwfg@mail.gmail.com>
 <CAJ_m3YCXqCd_8Xn90XfTdAXOzGoP=THufk3XR_ia4oHr+n5JGw@mail.gmail.com>
 <CAAL6JQgUDtZ6M_NZM3a-Rc1DxFJPTwL4bMzW_fEASAPg45+yew@mail.gmail.com>
 <CAN-3CBKVQiM_=eNBkD4w=1QUeycBODZESKLnyz95Bdk29L0aLg@mail.gmail.com>
 <CAL3q7H6Y-NJSoRYBaGy_ZxU=z6LxyxBnt5to+bmmONiTbe_8Wg@mail.gmail.com>
 <CAJNb-9p0YuRJS5hTgRqY8gZ10MSO-_hzG03oVXomJ32wZ3srTA@mail.gmail.com>
 <CAEyAqDtD_hwU7g4iqxbDGJNboQUvdarsezSqhbY_f_ckYTgCkQ@mail.gmail.com>
 <CAAL6JQjsPMVB3TzMuh9ntu1pjYbAPcF5L2o6fEeLzjhz5ffa-Q@mail.gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Sat, 27 Aug 2011 16:19:46 -0500
Message-ID: 
 <CAJ_m3YA4pBAwFA4mfOLT-x8Yx0dxhMawJHGmcFad9jB8_SZrzQ@mail.gmail.com>
Subject: Re: The _security object should be versioned
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 27, 2011 at 3:35 PM, Randall Leeds <randall.leeds@gmail.com> wr=
ote:
> On Sat, Aug 27, 2011 at 12:05, Chris Anderson <jchris@apache.org> wrote:
>
>> On Sat, Aug 27, 2011 at 9:14 AM, Benoit Chesneau <bchesneau@gmail.com>
>> wrote:
>>
>> > _security doc or object is something we need available each time we op=
en
>> a
>> > db thoug. So having it in db headers has a lot of sense imo. =A0If it'=
s
>> savd
>> > with #full_doc_* semantic does it means it will be saved in the db, an=
d
>> we
>> > keep a pointer to it in the db header ? Or would it still be saved in =
the
>> db
>> > header?
>> >
>> >
>> > - benoit
>> >
>>
>> Currently a pointer to it is stored in the db header. The pointer
>> could be to whatever, wouldn't change things. So if full_doc_info
>> solves the original question, that works for me.
>>
>> I think for 2.0 we should consider whether to move it to a _local/doc
>> or not. Part of the point of the original implementation is
>> simplicity. If it stops being simple we should feel free to refactor
>> as long as we don't break people's expectations.
>>
>
>
> How's this for a way forward?
>
> 1) Refactor couch_db_updater:merge_rev_trees so that the action of mergin=
g a
> revision tree is decoupled from the maintenance of the by_seq index. In
> particular, I would love to see a function which just merges a single
> document's revision tree. That code can be re-used for folding over all t=
he
> regular document updates that affect the _changes/by_seq index and also u=
sed
> for the _security object.
>
> 2) Promote _security to a #full_doc_info record. Keep a pointer to it in =
the
> db header still. Write the upgrade code.
>
> 3) Let the current _security API stay as it is (it has to until 2.0,
> right?), with clobbering/auto-rev-bump semantics. This is not so differen=
t
> from the case of regular document creation, where we treat it as an impli=
cit
> update to the {0, []} revision. That should make incomplete updates to a
> cluster-wide _security object resolvable for fork maintainers (I'm lookin=
g
> at you, Paul).
>
> 4) Bump any discussion of an explicit MVCC API at the HTTP level for
> _security and all discussion of _local docs to another time/thread.
>

Yes to all of this except bumping MVCC HTTP discussion. I haven't yet
convinced myself that its doable without exposing the standard _rev
semantics to clients. And as Chris mentions it'd probably already fit
into most people's current update patterns. It does seem like there's
a possibility to hide it from clients but I'm not sure that's
appropriate here.