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) <[EMAIL PROTECTED]> 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 !!
