[
https://issues.apache.org/jira/browse/GEODE-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284382#comment-16284382
]
ASF GitHub Bot commented on GEODE-3799:
---------------------------------------
nreich commented on a change in pull request #1109: GEODE-3799: Move backups
towards a pluggable architecture
URL: https://github.com/apache/geode/pull/1109#discussion_r155896387
##########
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/backup/BackupDefinition.java
##########
@@ -0,0 +1,83 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache.backup;
+
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Map;
+import java.util.Set;
+
+import org.apache.geode.cache.DiskStore;
+
+class BackupDefinition {
Review comment:
Good point on using an interface that only exposes the getters.
The RestoreScript is part of the BackupDefinition to remove its logic from
the BackupManager. Ultimately, we want to no longer have the script and instead
have a manifest file that details the files and checks that need to be done to
restore the backup (and do so in gemfire, not in a command line script), but
that is a future feature.
The different file types are because we store those files in different
directories in the backup, to prevent name collisions among other things. It is
true that we could probably just have a list of files and have the methods that
handle each type of file modify the path in the correct way. I think that the
logic of where in the backup the file should go does belong here instead of in
BackupManager.
I use Paths, generally, because they are now the prefered method of handling
file IO (see
https://docs.oracle.com/javase/tutorial/essential/io/legacy.html#), but also
the Files utility class takes Paths only (added at the same time as Path) and I
generally prefer using it (though there are still a few things that are easier
to do with Apache Commons)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Create plugin system for specifying where a backup is stored
> ------------------------------------------------------------
>
> Key: GEODE-3799
> URL: https://issues.apache.org/jira/browse/GEODE-3799
> Project: Geode
> Issue Type: Sub-task
> Components: persistence
> Reporter: Nick Reich
> Assignee: Nick Reich
>
> The current logic merges the moving/copying of files with the determining of
> what to backup. To make it possible to store a backup in cloud storage or
> other locations, we need to separate these concerns, putting the variable,
> location-based logic, into a plugin architecture.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
