Github user zenfenan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2440#discussion_r165660720
--- Diff:
nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/storage/ListAzureBlobStorage.java
---
@@ -106,7 +106,8 @@
attributes.put("azure.etag", entity.getEtag());
attributes.put("azure.primaryUri", entity.getPrimaryUri());
attributes.put("azure.secondaryUri", entity.getSecondaryUri());
- attributes.put("azure.blobname", entity.getName());
+ attributes.put("azure.blobname", entity.getBlobName());
+ attributes.put("filename", entity.getName());
--- End diff --
I dint use `filename` just because to find a use for `entity.getName()` The
filename attribute for ListAzureBlobStorage as of 1.5.0 has a large number as
its name, much like the filenames of flowfiles generated by GenerateFlowFiles
processor. The change here is intended to provide a meaningful filename i.e.
the actual name of the blob.
My assumption was that people would either be updating the filename using
UpdateAttribute/ExecuteScript (parsing the azure.primaryUri and taking the file
name) or simply ignoring the filename altogether. In that case, this change
won't affect, right? For ex: If people are overwriting filename attribute,
whatever this contribution produces as a filename will still be overwritten ( I
am again going with the assumption that they would either be parsing the
filename from the azure.primaryUri attribute since that's the only attribute
that provides us the blob name). If they aren't touching the filename
attribute, then this would just produce a meaningful filename. Hope you
understood what I'm trying to say.
---
