From dev-return-8259-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Fri Aug 04 16:07:59 2006 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 37175 invoked from network); 4 Aug 2006 16:07:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Aug 2006 16:07:59 -0000 Received: (qmail 69563 invoked by uid 500); 4 Aug 2006 16:07:57 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 69538 invoked by uid 500); 4 Aug 2006 16:07:57 -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 69529 invoked by uid 99); 4 Aug 2006 16:07:57 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Aug 2006 09:07:57 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of ntoper@gmail.com designates 64.233.182.190 as permitted sender) Received: from [64.233.182.190] (HELO nf-out-0910.google.com) (64.233.182.190) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Aug 2006 09:07:56 -0700 Received: by nf-out-0910.google.com with SMTP id n15so119330nfc for ; Fri, 04 Aug 2006 09:07:35 -0700 (PDT) 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:references; b=cwlMYPkfLLLebayY0T7Bv5cim+huX6+ht0MusJyI7d44CZEA/Iwt9bkH/00SoYnBWr1Oaeq++NF7xlXzTOs7PwpMEtj/oAUHvI+aC36PH8D9x3mzQmjfgp2WAeO29EM9soTjuazLhjn+ubSyGVS6roAhxBeggUz0MOAT2kT2HdA= Received: by 10.78.147.3 with SMTP id u3mr1606828hud; Fri, 04 Aug 2006 09:07:34 -0700 (PDT) Received: by 10.78.125.9 with HTTP; Fri, 4 Aug 2006 09:07:34 -0700 (PDT) Message-ID: Date: Fri, 4 Aug 2006 18:07:34 +0200 From: "Nicolas " To: dev@jackrabbit.apache.org Subject: Re: [jira] Commented: (JCR-442) Implement a backup tool In-Reply-To: <16918783.1154676975388.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_53166_20650131.1154707654666" References: <653998.1148469389882.JavaMail.jira@brutus> <16918783.1154676975388.JavaMail.jira@brutus> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_53166_20650131.1154707654666 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On a second thought with the point 2: reimporting prefixes and ns. There is 2 cases to consider during a partial restore (no issue for blank repository): 1/ The prefix already exists => We should throw an exception and stop the restore. If I update the namespace, the documetn already there would use a wrong namespace. Same issue, for the imported document if I don't restore the prefix. I could consider changing the namespace though. However, I would prefer to stop the restore and throw an exception. 2/ The namespace already exists => we would have two prefix using my code for the same Ns. Which is good, since we won't update the document (would we?) What do you think? Nicolas On 8/4/06, Jukka Zitting (JIRA) wrote: > > [ > http://issues.apache.org/jira/browse/JCR-442?page=comments#action_12425690] > > Jukka Zitting commented on JCR-442: > ----------------------------------- > > Thanks again, great progress! Some issues until I commit your changes: > > 1) I think it's better for now to stick with the standard > NamespaceRegistry methods for checking the existence of a namespace, even at > the inconvenience of having to catch an exception. It seems like your backup > tool ends up being quite general, so it might also be useful for other JCR > implementations! Thus, the fewer jackrabbit-specific methods you use, the > better. > > 2) It's better to use the namespace URI than the prefix when checking for > namespace existence. The prefix is just a shorthand for the namespace URI, > so it shouldn't be a problem if the namespace already exists with a > different prefix. > > 3) I think the setRepProps() method should be named setDescriptors() to > avoid introducing internal concepts at the public method layer. We might in > future decide to manage the repository descriptors as something else as a > properties hash, so the setDescriptors() name should better stand the test > of time. > > 4) The setDescriptors() method should ideally have some kind of an access > check that only permits the administrator to make those changes. I'm not > sure if the access control framework can do that yet, so you can just leave > a TODO on it for now. > > 5) The root node ID issue is a bit tricky. Normally it's the same > (cafebabe-cafe-babe-cafe-babecafebabe) in all repository instances, so there > shouldn't be any need to backup/restore it, but then Jackrabbit uses a file > to store the root ID so it's still kind of configurable. However, I think > that changing the root node ID of a repository may cause some unexpected > issues, so it's probably better not to backup/restore it. > > > > Implement a backup tool > > ----------------------- > > > > Key: JCR-442 > > URL: http://issues.apache.org/jira/browse/JCR-442 > > Project: Jackrabbit > > Issue Type: New Feature > > Reporter: Jukka Zitting > > Attachments: jackrabbit-1.patch.txt, patch, > patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, > patch-backup-060726.txt, patch-backup-060728.txt, patch-backup-060803.txt, > patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, > patch-jackrabbit-060725.txt, patch-jackrabbit-060726.txt, > patch-jackrabbit-060728.txt, patch-jr-060803.txt, patch.txt, patch.txt, > patch.txt, patch.txt > > > > > > Issue for tracking the progress of the Google Summer of Code project > assigned to Nicolas Toper. The original project requirements are: > > "Implement a tool for backing up and restoring content in an Apache > Jackrabbit content repository. In addition to the basic content hierarchies, > the tool should be able to efficiently manage binary content, node version > histories, custom node types, and namespace mappings. Incremental or > selective backups would be a nice addition, but not strictly necessary." > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > -- a+ Nico my blog! http://www.deviant-abstraction.net !! ------=_Part_53166_20650131.1154707654666--