You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2006/08/04 09:36:15 UTC
[jira] Commented: (JCR-442) Implement a backup tool
[ 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
Re: [jira] Commented: (JCR-442) Implement a backup tool
Posted by Nicolas <nt...@gmail.com>.
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) <ji...@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
>
>
>
--
a+
Nico
my blog! http://www.deviant-abstraction.net !!
Re: [jira] Commented: (JCR-442) Implement a backup tool
Posted by Nicolas <nt...@gmail.com>.
Agreed for safeRegisterNamespace but on this issue please see my other mail:
there are a couple of question to answer
On 8/4/06, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> On 8/4/06, Nicolas <nt...@gmail.com> wrote:
> > 1/ I disagree. It is a better programming practice not to launch
> exception
> > for this kind of issues. Besides, there should be a way to check if the
> > namespace is already or not registered. Maybe something to add to the
> next
> > version of JCR? What do you think?
>
> Agreed, but adding a custom method for checking namespace existence
> increases the coupling between the backup tool and Jackrabbit.
> Actually, you may want to use the safeRegisterNamespace() method I
> added a few months ago. Proposing to add that in JSR 283 is also an
> option, though I'm not sure if the use case is critical enough to
> warrant inclusion in the standard.
>
> > 3/4/5/ I will delete the backup code + restore code. Maybe I should just
> > comment it, in case we need in later. What do you think?
>
> Sounds good.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
--
a+
Nico
my blog! http://www.deviant-abstraction.net !!
Re: [jira] Commented: (JCR-442) Implement a backup tool
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/4/06, Nicolas <nt...@gmail.com> wrote:
> 1/ I disagree. It is a better programming practice not to launch exception
> for this kind of issues. Besides, there should be a way to check if the
> namespace is already or not registered. Maybe something to add to the next
> version of JCR? What do you think?
Agreed, but adding a custom method for checking namespace existence
increases the coupling between the backup tool and Jackrabbit.
Actually, you may want to use the safeRegisterNamespace() method I
added a few months ago. Proposing to add that in JSR 283 is also an
option, though I'm not sure if the use case is critical enough to
warrant inclusion in the standard.
> 3/4/5/ I will delete the backup code + restore code. Maybe I should just
> comment it, in case we need in later. What do you think?
Sounds good.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: [jira] Commented: (JCR-442) Implement a backup tool
Posted by Nicolas <nt...@gmail.com>.
Hi again,
1/ I disagree. It is a better programming practice not to launch exception
for this kind of issues. Besides, there should be a way to check if the
namespace is already or not registered. Maybe something to add to the next
version of JCR? What do you think?
2/ OK
3/4/5/ I will delete the backup code + restore code. Maybe I should just
comment it, in case we need in later. What do you think?
Nicolas
On 8/4/06, Jukka Zitting (JIRA) <ji...@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
>
>
>
--
a+
Nico
my blog! http://www.deviant-abstraction.net !!