jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-442) Implement a backup tool
Date Fri, 04 Aug 2006 07:36:15 GMT
    [ 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

        

Mime
View raw message