jfrazee commented on pull request #3906:
URL: https://github.com/apache/nifi/pull/3906#issuecomment-623016616
@turcsanyip More details below but the tl;dr is that I think this makes
sense, but `${filename}` doesn't currently contain the whole object name so I
think we'd have to break `ListAzureBlobStorage` to make the new default useful.
E.g., if you do a recursive listing and have `/test/test.txt` what you end
up with is:
```properties
azure.blobname = test/test.txt
filename = test.txt
path = ./
```
So if `FetchAzureBlobStorage` defaulted to `${filename}`, I think
`ListAzureBlobStorage` => `FetchAzureBlobStorage` will break unless we change
how `${filename}` is defined in `ListAzureBlobStorage`. But that will break
things for anyone currently using `${filename}` with the Blob processors.
Also, arguably, `${path}` is wrong and there's a bug here because that's not
the object's path. Comparing all this to `ListFile`, the behavior is different:
```properties
absolute.path = /tmp/nifi/test/
filename = test.txt
path = test/
```
S3 and GCS might be unique in the way they treat `${filename}`. A lot of
processors set `${filename}` to a bare filename. And the other
filesystem-oriented `Fetch` processors, if they have a default use
`${absolute.path}/${filename}` or `${path}/${filename}`.
Options:
1. Go with this PR.
2. Go for consistency with S3 and GCS, change `${filename}` to be the full
object name, use it as the default, potentially breaking flows that assume it's
the bare filename today.
3. Go for consistency with File, fix `${path}` and default to
`${path}/${filename}`, potentially breaking flows using `${path}` today. But
`${path}` is wrong, so is anyone using it?
4. Do nothing.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
