Problem

When importing structured metadata, Cloudinary requires you to use the external_ids for the field and field options (for enum and set fields). This is currently possible for the field names but becomes cumbersome for the field options.

I believe building in functionality to automatically map labels to external ids will be a good addition to the help speed up the migration process

Potential solutions

There are a number of possible solutions (my initial thoughts listed below):

1. Low touch: Pass a metadata object to input2ApiPayload to allow the user to map the external ids (without the need to call the Admin API on each load)
2. Medium touch: Create helper functions to get the external ids, for example getFieldExternalId and getFieldValueExternalId
3. Higher touch: Create a function that takes a JSON object and converts of the metadata (using labels) and converts it to external ids. This object can then be merged with other metadata values input2ApiPayload
4. Highest touch: Somehow we preprocess the row and pass the "initial" upload parameters that the user can then modify in input2ApiPayload. This could review each column in the CSV and try to map it to the expected upload parameters, this could be used for metadata but also Display name, resource type etc.

          Having "MIGRATED' as the default feels risky to me.

Should this not be set after we have the response?

I see there being 4 status':

• MIGRATED = New upload of an asset
• OVERWRITTEN = Public id already existed and overwrite was set to true (overwritten is in the response object)
• ALREADY EXISTED = Public id already existed and overwrite was set to false (existing is in the response object)
• FAILED = Error occurred

Originally posted by @mgriff in #7 (comment)

Some customers may have very large manifest files. In such a case, it may be useful to consider reading from the compressed manifest file and save disk space.

This could be an optional flag for the CLI.

When running the migration I don't want to have to set the log folder each time, I end up using a numbering system (i.e. run1, run2, run3) which doesn't add much value.

I propose we add an option to use a default folder path, initially still using the output-folder parameter but potentially making it the default in the future.

I propose we use the following format: logs/<cloud_name>/<todays_date>/<current_time>

Despite the name, CSV files do not always use commas as the delimiter. For example, the default for Excel in a number of EU countries is the semicolon.

We should add an option to configure the delimiter used in the CSV file