Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <16918783.1154676975388.JavaMail.jira@brutus>
Date: Fri, 4 Aug 2006 00:36:15 -0700 (PDT)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-442) Implement a backup tool
In-Reply-To: <653998.1148469389882.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ 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