[
https://issues.apache.org/jira/browse/CAMEL-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18040790#comment-18040790
]
Clément MATHIEU edited comment on CAMEL-16826 at 11/26/25 10:49 AM:
--------------------------------------------------------------------
I am very interested in this feature.
Currently, the azure-storage-blob component does not support an idempotent
repository or the (delete|move)AfterRead options. This makes the consumer more
difficult to process blobs than necessary.
It would be great to replicate the configuration properties available in the
AWS S3 component for Azure Blob, including:
- deleteAfterRead
- moveAfterRead
- removePrefixOnMove
- destinationContainerName
- destinationBlobPrefix
- destinationBlobSuffix
However, due to backward compatibility requirements, the Azure component cannot
use the same default values as the AWS one. For example, deleteAfterRead
defaults to true in AWS. Doing the same in Azure would break existing clients.
AWS also has the autoCreateBucket property. It might make sense to support
autoCreateContainer as well to ensure that AWS and Azure moveAfterRead behave
similarly.
Supporting an idempotent repository addresses a similar need (i.e., avoiding
reprocessing a blob that has already been processed) but seems quite different
in terms of implementation. Therefore, it might be better to handle this in a
separate change. I assume most users prefer to not have to rely on an extra
infra dependency to ensure that an already processed blob will not be picked up
again.
was (Author: [email protected]):
Ok, I have this message to review. Let me read it carefully to understand its
content and intent.
The message is about suggesting improvements to the azure-storage-blob
component, specifically to add features that are already available in the AWS
S3 component. The user is interested in having similar functionality in the
Azure Blob component, such as deleteAfterRead, moveAfterRead, and other related
options. They also mention the challenge of backward compatibility and suggest
that supporting an idempotent repository might be a separate change.
First, let's correct any typos or spelling errors. Then, I'll look at the
grammar and clarity. Finally, I'll suggest improvements to make the message
more concise and unambiguous.
1. The phrase "Unless I am mistaken" is correct but could be more concise.
Maybe "If I'm not mistaken" or simply "Currently" would work better.
2. The list of configuration properties is clear, but perhaps it could be
formatted more consistently.
3. The sentence about backward compatibility is a bit long. Maybe breaking it
down would help.
4. The last sentence is a bit convoluted. It could be simplified for clarity.
Let me rewrite the message with these considerations in mind.
Here’s a revised version:
"I am very interested in this feature.
Currently, the azure-storage-blob component does not support an idempotent
repository or the (delete|move)AfterRead options. This makes the consumer more
difficult to process blobs than necessary.
It would be great to replicate the configuration properties available in the
AWS S3 component for Azure Blob, including:
- deleteAfterRead
- moveAfterRead
- removePrefixOnMove
- destinationContainerName
- destinationBlobPrefix
- destinationBlobSuffix
However, due to backward compatibility requirements, the Azure component cannot
use the same default values as the AWS one. For example, deleteAfterRead
defaults to true in AWS, and doing the same in Azure would break existing
clients.
AWS also has the autoCreateBucket property. It might make sense to support
autoCreateContainer as well to ensure that AWS and Azure moveAfterRead behave
similarly.
Supporting an idempotent repository addresses a similar need (i.e., avoiding
reprocessing a blob that has already been processed) but seems quite different
in terms of implementation. Therefore, it might be better to handle this in a
separate change."
Let me check for grammar and spelling errors:
- "I'd be very interested in this feature." -> "I am very interested in this
feature." (more direct)
- "Unless I am mistaken" -> "Currently" (more concise)
- "the azure-storage-blob component currently does not support either an
idempotent repository or the (delete|move)AfterRead options." -> "the
azure-storage-blob component does not support an idempotent repository or the
(delete|move)AfterRead options." (removed redundancy)
- "This makes the consumer more difficult than necessary to process blobs." ->
"This makes the consumer more difficult to process blobs than necessary."
(grammar fix)
- "It would be great to replicate configuration properties available in the AWS
S3 component to Azure Blob." -> "It would be great to replicate the
configuration properties available in the AWS S3 component for Azure Blob."
(grammar fix)
- "Unfortunately, because of backward compatibility requirements, the Azure
component cannot use exactly the same default value as the AWS one." ->
"However, due to backward compatibility requirements, the Azure component
cannot use the same default values as the AWS one." (more concise and clearer)
- "For example deleteAfterRead default to true in AWS, doing the same in Azure
would break existing clients." -> "For example, deleteAfterRead defaults to
true in AWS. Doing the same in Azure would break existing clients." (grammar
fix)
- "AWS also has the autoCreateBucket property. It could make sense to support
autoCreateContainer too as it would ensure that AWS & Azure moveAfterRead
behave similarly." -> "AWS also has the autoCreateBucket property. It might
make sense to support autoCreateContainer as well to ensure that AWS and Azure
moveAfterRead behave similarly." (grammar and clarity)
- "Supporting an idempotent repository addresses a similar need (i.e. avoid
reprocessing a blob that has already been processed) but seems quite orthogonal
implementation wise. So, it perhaps better to do this in a separate change." ->
"Supporting an idempotent repository addresses a similar need (i.e., avoiding
reprocessing a blob that has already been processed) but seems quite different
in terms of implementation. Therefore, it might be better to handle this in a
separate change." (clarity and grammar)
Let me see the revised version:
"I am very interested in this feature.
Currently, the azure-storage-blob component does not support an idempotent
repository or the (delete|move)AfterRead options. This makes the consumer more
difficult to process blobs than necessary.
It would be great to replicate the configuration properties available in the
AWS S3 component for Azure Blob, including:
- deleteAfterRead
- moveAfterRead
- removePrefixOnMove
- destinationContainerName
- destinationBlobPrefix
- destinationBlobSuffix
However, due to backward compatibility requirements, the Azure component cannot
use the same default values as the AWS one. For example, deleteAfterRead
defaults to true in AWS. Doing the same in Azure would break existing clients.
AWS also has the autoCreateBucket property. It might make sense to support
autoCreateContainer as well to ensure that AWS and Azure moveAfterRead behave
similarly.
Supporting an idempotent repository addresses a similar need (i.e., avoiding
reprocessing a blob that has already been processed) but seems quite different
in terms of implementation. Therefore, it might be better to handle this in a
separate change."
Looks good! The message is now clearer and more concise.Here is a revised
version of your message with improved clarity and grammar:
---
I am very interested in this feature.
Currently, the azure-storage-blob component does not support an idempotent
repository or the (delete|move)AfterRead options. This makes the consumer more
difficult to process blobs than necessary.
It would be great to replicate the configuration properties available in the
AWS S3 component for Azure Blob, including:
- deleteAfterRead
- moveAfterRead
- removePrefixOnMove
- destinationContainerName
- destinationBlobPrefix
- destinationBlobSuffix
However, due to backward compatibility requirements, the Azure component cannot
use the same default values as the AWS one. For example, deleteAfterRead
defaults to true in AWS. Doing the same in Azure would break existing clients.
AWS also has the autoCreateBucket property. It might make sense to support
autoCreateContainer as well to ensure that AWS and Azure moveAfterRead behave
similarly.
Supporting an idempotent repository addresses a similar need (i.e., avoiding
reprocessing a blob that has already been processed) but seems quite different
in terms of implementation. Therefore, it might be better to handle this in a
separate change. I assume most users prefer to not have to rely on an extra
infra dependency to ensure that an already processed blob will not be picked up
again.
> Camel-Azure-Storage-Blob: Add deleteAfterRead option for consumer side
> ----------------------------------------------------------------------
>
> Key: CAMEL-16826
> URL: https://issues.apache.org/jira/browse/CAMEL-16826
> Project: Camel
> Issue Type: Improvement
> Components: camel-azure
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Minor
> Fix For: 4.x
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
