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.


---

Reply via email to