jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas " <nto...@gmail.com>
Subject Re: [jira] Commented: (JCR-442) Implement a backup tool
Date Fri, 04 Aug 2006 16:07:34 GMT
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

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

What do you think?


On 8/4/06, Jukka Zitting (JIRA) <jira@apache.org> 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

my blog! http://www.deviant-abstraction.net !!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message