Is your feature request related to a problem? Please describe.
To create an attachment with the sfdx data:record:create command, the file body (base64 encoded) needs to be passed as a parameter in the --values "Body='<my-large-body>'" parameter. Unfortunately, shell commands are limited in length (eg 1Mb on Macos) which limits the size of attachments which can be created by sfdx CLI.
What are you trying to do
I am trying to create a Salesforce Attachment object by command line with sfdx data:record:create command
Describe the solution you'd like
It would be nice to have an option to pass any large parameters as filenames, which the command would read and base64-encode before passing the data in to the Salesforce REST API to create the Attachment.
For example, we could imagine :
sfdx data:record:create \
--sobject Attachment \
--values "ParentId='xxxxxx' ContentType='pdf' Name='My PDF File'" \
--valuesbyfile "Body='./myfile.pdf'"
Describe alternatives you've considered
The only alternative I have imagined is to code this myself, to load the file body contents directly into the REST API request sent to Salesforce, without passing it through the CLI as a parameter.
Additional context
This could also apply to creating ContentVersion objects.
Is your feature request related to a problem? Please describe.
To create an attachment with the
sfdx data:record:createcommand, the file body (base64 encoded) needs to be passed as a parameter in the--values "Body='<my-large-body>'"parameter. Unfortunately, shell commands are limited in length (eg 1Mb on Macos) which limits the size of attachments which can be created bysfdxCLI.What are you trying to do
I am trying to create a Salesforce Attachment object by command line with
sfdx data:record:createcommandDescribe the solution you'd like
It would be nice to have an option to pass any large parameters as filenames, which the command would read and base64-encode before passing the data in to the Salesforce REST API to create the Attachment.
For example, we could imagine :
Describe alternatives you've considered
The only alternative I have imagined is to code this myself, to load the file body contents directly into the REST API request sent to Salesforce, without passing it through the CLI as a parameter.
Additional context
This could also apply to creating ContentVersion objects.