From oak-dev-return-510-apmail-jackrabbit-oak-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Fri Mar 30 15:44:16 2012 Return-Path: X-Original-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8C9CD9D50 for ; Fri, 30 Mar 2012 15:44:16 +0000 (UTC) Received: (qmail 18288 invoked by uid 500); 30 Mar 2012 15:44:16 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 18254 invoked by uid 500); 30 Mar 2012 15:44:16 -0000 Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oak-dev@jackrabbit.apache.org Delivered-To: mailing list oak-dev@jackrabbit.apache.org Received: (qmail 18242 invoked by uid 99); 30 Mar 2012 15:44:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Mar 2012 15:44:16 +0000 X-ASF-Spam-Status: No, hits=-1.6 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.18.1.23] (HELO exprod6og109.obsmtp.com) (64.18.1.23) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Mar 2012 15:44:07 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKT3XUsj7I42uoPGMw3+RKxj6mJsnvHBOs@postini.com; Fri, 30 Mar 2012 08:43:47 PDT Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q2UFhjvq000825 for ; Fri, 30 Mar 2012 08:43:45 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q2UFhi2H015156 for ; Fri, 30 Mar 2012 08:43:44 -0700 (PDT) Received: from eurhub01.eur.adobe.com (10.128.4.30) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 30 Mar 2012 08:43:44 -0700 Received: from susi.local (10.136.133.34) by eurhub01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.192.1; Fri, 30 Mar 2012 16:43:42 +0100 Message-ID: <4F75D4AE.2080103@apache.org> Date: Fri, 30 Mar 2012 16:43:42 +0100 From: =?ISO-8859-1?Q?Michael_D=FCrig?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Subject: Re: oak-api and move operations References: <4F74D366.2050503@gmail.com> <4F75A19C.4020109@apache.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 30.3.12 15:20, Stefan Guggisberg wrote: > On Fri, Mar 30, 2012 at 3:45 PM, Jukka Zitting wrote: >> Hi, >> >> On Fri, Mar 30, 2012 at 2:25 PM, Stefan Guggisberg >> wrote: >>> On Fri, Mar 30, 2012 at 2:18 PM, Jukka Zitting wrote: >>>> Exactly. IMHO we should adjust the MK interface to support this. The >>>> solution should also address handling of large imports. >>> >>> sorry, i can't follow you here. could you please elaborate? >> >> The main trouble here is that oak-core currently needs to keep the >> full transient space in memory (or in some other custom non-MK >> storage) and then serialize it all to a single JSOP string during >> save(). >> >> It would be much more convenient if the changes could be incrementally >> sent to the MicroKernel and tracked as a standard content tree just >> like any other content. This way we wouldn't need to come up with a >> separate storage mechanism in oak-core or use temporary subtrees in >> the main repository to work around this limitation. >> >> One way of dealing with this on the MK level would be to introduce the >> concept of "private branches" that are only visible to a single client >> until explicitly merged back to the main repository. A quick draft of >> what this could look like: >> >> String addLotsOfData(MicroKernel mk) { >> String baseRevision = mk.getHeadRevision(); >> String branchRevision = mk.branch(baseRevision); >> for (int i = 0; i< 1000000; i++) { >> branchRevision = mk.commit( >> "/", "+\"node" + i + "\":{}", branchRevision, null); >> } >> return mk.merge(branchRevision, baseRevision); >> } >> > > good point. the versioning model of the mk has been strictly linear so far > but i guess your proposal makes sense. we'll have to take into account > potential implications (gc, getJournal etc) but currently i don't see any > real problems with supporting 'private' branches. Just as an aside, this is essentially the same I proposed as early as on our first meeting on June 23th last year. I'd wasn't considered a good point at all back then... Michael > > cheers > stefan > >> BR, >> >> Jukka Zitting