Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 96864 invoked from network); 25 Nov 2006 14:42:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Nov 2006 14:42:21 -0000 Received: (qmail 19136 invoked by uid 500); 25 Nov 2006 11:55:49 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 18956 invoked by uid 500); 25 Nov 2006 11:55:49 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 18947 invoked by uid 99); 25 Nov 2006 11:55:48 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Nov 2006 03:55:48 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of stefan.guggisberg@gmail.com designates 64.233.182.191 as permitted sender) Received: from [64.233.182.191] (HELO nf-out-0910.google.com) (64.233.182.191) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Nov 2006 03:55:37 -0800 Received: by nf-out-0910.google.com with SMTP id x4so1597534nfb for ; Sat, 25 Nov 2006 03:55:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lD1cl8SQk3LXcOADoWPIFBu2aVLa/L62FPjaaUXgOv9pvLJ6fBlhHj24pLiGaDji5AhtJgmie5pfGVeq2L5lBAmXaDRaCc9WBM2y2TRo9zBQ7a+M892V/F/8KPYqGnNv3MdiaxHcweSSM/hY81h+/NN4HuD7oGGd0FunQhdgaqk= Received: by 10.78.183.15 with SMTP id g15mr11306830huf.1164455715878; Sat, 25 Nov 2006 03:55:15 -0800 (PST) Received: by 10.78.160.11 with HTTP; Sat, 25 Nov 2006 03:55:15 -0800 (PST) Message-ID: <90a8d1c00611250355x12529dd8vada59901e29b51c7@mail.gmail.com> Date: Sat, 25 Nov 2006 12:55:15 +0100 From: "Stefan Guggisberg" To: dev@jackrabbit.apache.org Subject: Re: Import in versionStorage In-Reply-To: <510143ac0611250253n68c95851x186d4d48758a81db@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <90a8d1c00611250053k73845e9en2ee83d9e508e497d@mail.gmail.com> <510143ac0611250253n68c95851x186d4d48758a81db@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org On 11/25/06, Jukka Zitting wrote: > Hi, > > On 11/25/06, Stefan Guggisberg wrote: > > On 11/24/06, SADAUNE Frederique (EURIWARE) > > wrote: > > > I want to import documents in Jackrabbit's repository but I don't manage > > > to import their different versions. > > > > > > Is there another way than checkout(),checkin() ? > > > > > > The backup tool sends a ConstraintViolationException due to the node's > > > protected property when trying to import directly on the versionStorage. > > > > unless there is a really compelling reason i would strongly discourage to > > manipulate meta data directly and rather use the appropriate api methods. > > > > after all there's a reason why the meta data is 'protected'. > > I think Frederique's concern is valid, there needs to be a way to > restore not only current versions but also the version histories of > nodes from a backup. This is the key reason for extending the > WorkspaceImporter functionality to meet the needs of Nicolas' backup > tool. i interpreted frederique's use case as 'importing' new documents, not restoring a jackrabbit backup. i might have got him wrong though. wrt WorkspaceImporter: i agree that it's not suited for restoring meta data, it was not designed for this use case and IMO it's the wrong approach as i've pointed out repeatedly. 'import' and 'restore' operations have IMO completely different semantics. cheers stefan > > The checkin/checkout methods are not expressive enough to fully > restore the version history of a node. For example there is no way to > control the jcr:created timestamps of the checked in versions. > > BR, > > Jukka Zitting >