I thought about a mutually exclusive —file and —dir, but in that case, -—file is required for standard and —path required for parallel export, which I think could be better than overloading —file, but still has potential for confusion.
The idea of deprecating —file in favor of path is interesting. I wonder if instead of making them mutually exclusive to start, having —path be able to support both modes from the start would be better? That way —file could still be used for the existing mode, but —path could be used instead (and override —file is both given?): that would provide a clear path forward for how the command should be used, while fully supporting existing workflows. We need to continue to support both modes, as only Partitioned Regions can make use of parallel export (it is parallelized on a bucket level). On Tue, Aug 22, 2017 at 12:55 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > How about deprecate —file and replace with —path? In the transition make > them mutually exclusive and —path required for —parallel. > > Any reason to not just make all export parallel rather than supporting two > different modes? > > -Jake > > > Sent from my iPhone > > > On Aug 22, 2017, at 12:27 PM, Kenneth Howe <kh...@pivotal.io> wrote: > > > > I agrees that overloading the “file” option seems like a bad idea. As an > alternative to separate commands, what about mutually exclusive options, > ‘—file’ and ‘—dir’? > > > > If you go for implementing the new functionality as a separate command, > I would suggest calling the gfsh commands: “export data-parallel” and > “import data-parallel" > > > >> On Aug 22, 2017, at 11:32 AM, Nick Reich <nre...@pivotal.io> wrote: > >> > >> Team, > >> > >> I am working on exposing the parallel export/import of snapshots through > >> gfsh and would appreciate input on the best approach to adding to / > >> updating the existing interface. > >> > >> Currently, ExportDataCommand and ImportDataCommand take a region name, a > >> member to run the command on, and a file location (that must end in > .gfd). > >> Parallel import and export require a directory location instead of a > single > >> file name (as there can be multiple files and need for uniquely named > >> files). It is possible to add a parallel flag and have the meaning of > the > >> "file" parameter be different depending on that flag, but that seems > overly > >> confusing to me. I am instead leaning towards creating new commands > (e.g. > >> ParallelExportDataCommand) that has a "directory" parameter to replace > >> "file", but is otherwise identical in usage to the existing commands. > >> > >> Do others have different views or approaches to suggest? > > >
