[
https://issues.apache.org/jira/browse/SOLR-15359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17325957#comment-17325957
]
Bruno Roustant commented on SOLR-15359:
---------------------------------------
+1 to precise the intent of the API.
I believe the API should create the parent directories if needed. Otherwise the
calling code ends up doing this code less efficiently: the caller has to make
multiple calls to create successively the directories (which is inefficient for
remote repositories with latency), while it may be optimized by an
implementation-specific BackupRepository that knows the repository.
> Clarify BackupRepository.createDirectory() semantics
> ----------------------------------------------------
>
> Key: SOLR-15359
> URL: https://issues.apache.org/jira/browse/SOLR-15359
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
> Affects Versions: main (9.0), 8.8.2
> Reporter: Jason Gerlowski
> Priority: Minor
>
> The BackupRepository abstraction (used by backup code to plug in various
> storage backends) has a createDirectory method with ambiguous semantics. In
> short, it's unclear whether the method is intended to act as {{mkdir}} or
> {{mkdir -p}}. Should it create any missing parent directories, or should it
> error out if a parent directory doesn't exist?
> Solr's current backup code avoids running afoul of this mostly by
> coincidence. Anywhere that nested directories are used, backup code makes a
> createDirectory call for each one. But this has allowed the different
> implementations to diverge. LocalFileSystemRepository throws an error if a
> parent directory doesn't exist, but HdfsBackupRepository quietly creates any
> missing parent directories.
> We should decide how we want this to behave, so that BackupRepository will
> serve as a better general purpose API for file/directory storage. Once
> decided, existing implementations should be brought into line.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
