[
https://issues.apache.org/jira/browse/OAK-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574516#comment-16574516
]
Michael Dürig edited comment on OAK-7672 at 8/9/18 11:56 AM:
-------------------------------------------------------------
[~mduerig], [~tomek.rekawek] could you please take a look at the attached patch?
/cc [~frm]
P.S. One of the concerns I had with this patch was where exactly to put
{{SegmentCopy}}. It finally landed in {{oak-segment-azure}} because it depends
on both {{oak-segment-tar}} and {{oak-segment-azure}} and didn't want to mingle
with dependencies, but logically it would belong to a separate module,
addressing concerns common to all {{SegmentNodeStore}} s. How about a separate
issue for creating an {{oak-segment-tool}} module responsible for exactly this
stuff?
was (Author: dulceanu):
[~mduerig], [~tomek.rekawek] could you please take a look at the attached patch?
/cc [~frm]
P.S. One of the concerns I had with this patch was where exactly to put
{{SegmentCopy}}. It finally landed in {{oak-segment-azure}} because it depends
on both {{oak-segment-tar}} and {{oak-segment-azure}} and didn't want to mingle
with dependencies, but logically it would belong to a separate module,
addressing concerns common to all {{SegmentNodeStore}}s. How about a separate
issue for creating an {{oak-segment-tool}} module responsible for exactly this
stuff?
> Introduce oak-run segment-copy for moving around segments in different
> storages
> -------------------------------------------------------------------------------
>
> Key: OAK-7672
> URL: https://issues.apache.org/jira/browse/OAK-7672
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-run, segment-tar
> Reporter: Andrei Dulceanu
> Assignee: Andrei Dulceanu
> Priority: Major
> Labels: tooling
> Fix For: 1.10, 1.9.7
>
> Attachments: OAK-7672.patch
>
>
> Often there's the need to transform a type of {{SegmentStore}} (e.g. local
> TarMK) into *the exact same* counter-part, using another persistence type
> (e.g. Azure Segment Store). While {{oak-upgrade}} partially solves this
> through sidegrades (see OAK-7623), there's a gap in the final content because
> of the level at which {{oak-upgrade}} operates (node store level). Therefore,
> the resulting sidegraded repository doesn't contain all the (possibly stale,
> unreferenced) data from the original repository, but only the latest head
> state. A side effect of this is that the resulting repository is always
> compacted.
> Introducing a new command in {{oak-run}}, namely {{segment-copy}}, would
> allow us to operate at a lower level (i.e. segment persistence), dealing only
> with constructs from {{org.apache.jackrabbit.oak.segment.spi.persistence}}:
> journal file, archives and archive entries. This way the only focus of this
> process would be to "translate" a segment between two persistence formats,
> without caring about the node logic stored inside (referenced/unreferenced
> node/property).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
