[
https://issues.apache.org/jira/browse/OAK-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14547788#comment-14547788
]
Julian Sedding commented on OAK-2626:
-------------------------------------
[~chetanm] The idea here is indeed to avoid FileSystem access. In
{{FileDataStore#getRecordIfStored()}} a call to {{File.exists()}} is done. In
the upgrade scenario that turned out to take significant time on my Mac Book
Pro with SSD. The logic in this patch bypasses FS access and reduces it to a
string operation. I intended to make any reliance on implementation details
optional. So the logic should fall back to public APIs if the optimization
fails.
This is especially interesting when re-running an upgrade with few changes to
the source content, i.e. an incremental upgrade (which requires some of my
other patches).
> Optimize binary comparison for merge during upgrade
> ----------------------------------------------------
>
> Key: OAK-2626
> URL: https://issues.apache.org/jira/browse/OAK-2626
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: upgrade
> Affects Versions: 1.1.7
> Reporter: Julian Sedding
> Priority: Minor
> Attachments: OAK-2626.patch, incremental-upgrade-no-changes.png
>
>
> In OAK-2619 I propose to support repeated upgrades into the same NodeStore.
> This issue does not optimizate the first run, but any subsequent run benefits
> from the proposed changes.
> One use-case for this feature is to import all content several days before
> the upgrade and then copy only the delta on the day of the upgrade.
> Assuming that both the source and target repositories use the same
> FileDataStore, binaries could be efficiently compared by their references.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
