[ 
https://issues.apache.org/jira/browse/OAK-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629734#comment-14629734
 ] 

Manfred Baedke commented on OAK-2619:
-------------------------------------

Hi [~jsedding],

bq. It feels odd, however, that the upgrade code needs to take care of 
implementation details of the DocumentNodeStore.

Absolutely. I'm even more reluctant to add some magic based on instanceof 
checks, so I think we should add an extra option for the maximal name length. 
WDYT?

> Repeated upgrades
> -----------------
>
>                 Key: OAK-2619
>                 URL: https://issues.apache.org/jira/browse/OAK-2619
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: upgrade
>    Affects Versions: 1.1.7
>            Reporter: Julian Sedding
>            Assignee: Manfred Baedke
>            Priority: Minor
>             Fix For: 1.3.3
>
>         Attachments: OAK-2619-v2.patch, OAK-2619.patch, 
> incremental-upgrade-no-changes-mongo.png, 
> incremental-upgrade-no-changes-tar.png, initial-upgrade-mongo.png, 
> initial-upgrade-tar.png
>
>
> When upgrading from Jackrabbit 2 to Oak there are several scenarios that 
> could benefit from the ability to upgrade repeatedly into one target 
> repository.
> E.g. a migration process might look as follows:
> # upgrade a backup of a large repository a week before go-live
> # run the upgrade again every night (commit-hooks only handle delta)
> # run the upgrade one final time before go-live (commit-hooks only handle 
> delta)
> In this scenario each upgrade would require a full traversal of the source 
> repository. However, if done right, only the delta needs to be written and 
> the commit-hooks also only need to process the delta.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to