[
https://issues.apache.org/jira/browse/SOLR-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276689#comment-15276689
]
Mark Miller commented on SOLR-9055:
-----------------------------------
bq. Yes we just need IndexInput and not the entire directory implementation.
Or even just something that can read the start of files and do the same hash
calc, or does the hash calc while copying...but yeah, probably by an IndexInput
usually.
I have not had a chance to see why we do this though. I know we do it when
replicating because you are copying a lucene index into an existing index. But
when backing up, you don't expect any files to already exist do you? Can't you
you just ensure the backup is only done to new / empty locations? I have to
look at some more context still though, I've only looked at the couple lines
pointed at github above.
> Make collection backup/restore extensible
> -----------------------------------------
>
> Key: SOLR-9055
> URL: https://issues.apache.org/jira/browse/SOLR-9055
> Project: Solr
> Issue Type: Task
> Reporter: Hrishikesh Gadre
> Assignee: Mark Miller
> Attachments: SOLR-9055.patch, SOLR-9055.patch
>
>
> SOLR-5750 implemented backup/restore API for Solr. This JIRA is to track the
> code cleanup/refactoring. Specifically following improvements should be made,
> - Add Solr/Lucene version to check the compatibility between the backup
> version and the version of Solr on which it is being restored.
> - Add a backup implementation version to check the compatibility between the
> "restore" implementation and backup format.
> - Introduce a Strategy interface to define how the Solr index data is backed
> up (e.g. using file copy approach).
> - Introduce a Repository interface to define the file-system used to store
> the backup data. (currently works only with local file system but can be
> extended). This should be enhanced to introduce support for "registering"
> repositories (e.g. HDFS, S3 etc.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
