[
https://issues.apache.org/jira/browse/HADOOP-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616203#comment-15616203
]
Lei (Eddy) Xu commented on HADOOP-13631:
----------------------------------------
Hi, [~fabbri]
Thanks for the patch.
{code}
void move(Collection<Path> pathsToDelete, Collection<PathMetadata>
pathsToCreate) throws IOException;
{code}
Can we move this logic into {{LocalMetadataStore}} and keep
{{MetadataStore#move(src, dst)}} as it is? The concerns I have are that the
interface exposes the implementation details of the current
{{LocalMetadataStore}} implementation, but not necessary true for other
implementations. For example, if we have a metadata store that uses trees
(i.e., NameNode :) ) to implement the namespace, this operation can simply be
done by moving {{TreeNode (src)}} to {{TreeNode(dst)}}, and all the subtrees
are good to go. And for {{DynamoDB}} or {{RDS}} implementations, they might
want to update {{parent,fileName}} pair in place without trying to match source
and destiny files from the two collections.
I do think that this move logic makes sense in {{LocalMetadataStore}}. And as
now each {{LocalMetadataStore}} has a {{FileSystem}} instance, it should be
easy to get these two collections underneath of {{LocalMetadataStore#move(src,
dst)}}?
Thanks.
> S3Guard: implement move() for LocalMetadataStore, add unit tests
> ----------------------------------------------------------------
>
> Key: HADOOP-13631
> URL: https://issues.apache.org/jira/browse/HADOOP-13631
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Reporter: Aaron Fabbri
> Assignee: Aaron Fabbri
> Attachments: HADOOP-13631-HADOOP-13345.001.patch
>
>
> Building on HADOOP-13573 and HADOOP-13452, implement move() in
> LocalMetadataStore and associated MetadataStore unit tests.
> (Making this a separate JIRA to break up work into decent-sized and
> reviewable chunks.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]