From oak-dev-return-3036-apmail-jackrabbit-oak-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Dec 4 13:03:21 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 5E350E716 for ; Tue, 4 Dec 2012 13:03:21 +0000 (UTC) Received: (qmail 23999 invoked by uid 500); 4 Dec 2012 13:03:21 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 23783 invoked by uid 500); 4 Dec 2012 13:03:15 -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 23732 invoked by uid 99); 4 Dec 2012 13:03:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Dec 2012 13:03:13 +0000 X-ASF-Spam-Status: No, hits=-1.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mreutegg@adobe.com designates 64.18.1.33 as permitted sender) Received: from [64.18.1.33] (HELO exprod6og114.obsmtp.com) (64.18.1.33) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Dec 2012 13:03:05 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKUL30c8kVJ9rnvn+0oZyW0cWFfea9Pw5a@postini.com; Tue, 04 Dec 2012 05:02:44 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qB4D2gAi019275 for ; Tue, 4 Dec 2012 05:02:43 -0800 (PST) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qB4D2gXL021108 for ; Tue, 4 Dec 2012 05:02:42 -0800 (PST) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 4 Dec 2012 05:02:41 -0800 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Tue, 4 Dec 2012 13:02:40 +0000 From: Marcel Reutegger To: "oak-dev@jackrabbit.apache.org" Date: Tue, 4 Dec 2012 13:02:38 +0000 Subject: RE: Oak & JCR versioning Thread-Topic: Oak & JCR versioning Thread-Index: Ac3RbNmS158Nq1NaSTeKQyYs8j2T8wAroNog Message-ID: <9C0FC4C8E9C29945B01766FC7F9D389817293D52A8@eurmbx01.eur.adobe.com> References: <9C0FC4C8E9C29945B01766FC7F9D389817293D50BC@eurmbx01.eur.adobe.com> <9C0FC4C8E9C29945B01766FC7F9D389817293D5211@eurmbx01.eur.adobe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Hi, > From: Jukka Zitting [mailto:jukka.zitting@gmail.com] > On Mon, Dec 3, 2012 at 5:17 PM, Marcel Reutegger > wrote: > >> or explicitly modify a version history > > > > why would you want to do that? I think it is better to limit the possib= le > > modifications to what the spec allows you to do. >=20 > There are various potential scenarios where you might want to do > something like that. For example when modifying a node type, it would > be useful if I could also adjust all past versions of affected nodes > to match the new type definition. Otherwise I wouldn't be able to > check out those versions anymore. this implies that oak-jcr supports non-trivial node type modification. do we really want to go there? to me this sounds like opening pandorra's box :-/ trivial node type changes would still be OK because no changes are required on frozen nodes. > >> or a checked out node in ways that don't fit within > >> the mentioned predefined operations. > > > > there wouldn't be any restrictions in this case. you can do whatever > > you want with a checked out node. I probably missed something. > > Can you describe in more detail what you mean here? >=20 > One good example of a potential versioning operation that isn't > covered by JCR 2.0 is rebase, i.e. adjusting the base version of a > node without having to first restore that version and then re-apply > all changes. >=20 > It might be that we never need to support anything like that in > practice, but I'd rather design the system so that we don't need to > change the core implementation to support extensions like that. I don't think this would require changes to the core implementation. it would just be one more hook watching jcr:baseVersion. similar to a restore the hook could allow modifications to jcr:baseVersion when it is checked out and then perform the rebase.=20 > >> I wouldn't want to run into cases > >> where a client can't do something it wants because doing so would > >> trigger unwanted content modifications by the commit hooks. > > > > can you give an example? >=20 > One potential use case would be a "partial checkin" where we want to > create a new version with just a subset of the modified content in the > checked out node (like you can easily do with svn or git). Can we do > that without triggering a full checkin or checkpoint operation from a > content hook? you mean checkin a node, which has two modified properties, but we only want to check in the change to one of the properties? hmm, no that wouldn't be possible easily. but with JCR that's not possible either and as the subject indicates, this is about JCR versioning ;)=20 > > yes, that would also work. though, it requires you to use those classes > > on top of the oak-api when you want to provide remoting for version > > operations. with my approach one could simply perform content > > modifications on the oak api to trigger the version operations. >=20 > A remoting layer can be made to expose also higher level operations > above the Oak API. For example, if the versioning code was > encapsulated in something like a VersioningOperations utility class > the oak-http component could use it to provide direct HTTP access to > such versioning oprations. A remote oak-jcr client could then use > something like a VersioningOperationsOverHttp subclass to replace the > direct Oak API code with higher-level alternatives. right, we'd have to introduce yet another plugin mechanism in oak-http. but we might have to do that anyway... the major benefit I see with a commit hook based approach is that we can seal off the version store and make it read-only. I think this simplifies the process of mounting the version store into the workspace. at least at this stage we wouldn't have to deal with changes that affect a workspace and the version store. regards marcel