You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Chetan Mehrotra <ch...@gmail.com> on 2018/02/23 08:27:20 UTC
ArtifactStore Attachment support and deletions
I am working on a custom ArtifactStore implementation. While
implementing the support for attachments it appears there is api to
add and read but no api to delete an attachment.
This works fine for current CouchDB store as attachment lifecycle is
tied to document to which the attachment is being attached i.e. if
that document is deleted then all attached documents are also removed.
However for setups where the attachments are stored in a separate
Blob/Object storage it needs to be explicitly handled.
Proposal A - Explicit delete call
----------------------------------------------
Add a new api for deleting attachment
ArtifactStore#deleteAttachment(doc: DocInfo, name: String)
This api is invoked in addition to ArtifactStore#del say in
WriteOps#deleteEntity and thus ensure that any related attachments are
also removed when the owning entity is removed
Proposal B - Implicit delete
---------------------------------------
Most Blob storage services allow querying and deleting by prefix in
blob id. So while storing the attachment the BlobId can be set to
doc.id + "/" + attachmentName
And when any entity is deleted then the ArtifactStore can make a call
to delete all blobs where blobId starts with doc.id
Doing it for every delete may add overhead as only action types are
making use of attachments currently. So here ArtifactStore may need to
"interpret" the entityType of the document being deleted and see if
its action then also make a delete call for attachment
Any suggestion on which approach to take here? Proposal #B requires no
change in OpenWhisk and can be done in custom implementation
Chetan Mehrotra
Re: ArtifactStore Attachment support and deletions
Posted by Chetan Mehrotra <ch...@gmail.com>.
Thanks Rodric for the suggestion. Opened
https://github.com/apache/incubator-openwhisk/issues/3356 to track
this
Chetan Mehrotra
On Sat, Feb 24, 2018 at 11:16 AM, Rodric Rabbah <ro...@gmail.com> wrote:
> How about a hybrid approach?
>
> The low level interface introduces delete attachment and the whisk store for whisk actions overrides del to manage the attachment?
>
> I haven’t tinkered with the code to try this out.
>
> -r
>
>> On Feb 23, 2018, at 3:27 AM, Chetan Mehrotra <ch...@gmail.com> wrote:
>>
>> I am working on a custom ArtifactStore implementation. While
>> implementing the support for attachments it appears there is api to
>> add and read but no api to delete an attachment.
>>
>> This works fine for current CouchDB store as attachment lifecycle is
>> tied to document to which the attachment is being attached i.e. if
>> that document is deleted then all attached documents are also removed.
>>
>> However for setups where the attachments are stored in a separate
>> Blob/Object storage it needs to be explicitly handled.
>>
>> Proposal A - Explicit delete call
>> ----------------------------------------------
>>
>> Add a new api for deleting attachment
>>
>> ArtifactStore#deleteAttachment(doc: DocInfo, name: String)
>>
>> This api is invoked in addition to ArtifactStore#del say in
>> WriteOps#deleteEntity and thus ensure that any related attachments are
>> also removed when the owning entity is removed
>>
>>
>> Proposal B - Implicit delete
>> ---------------------------------------
>>
>> Most Blob storage services allow querying and deleting by prefix in
>> blob id. So while storing the attachment the BlobId can be set to
>> doc.id + "/" + attachmentName
>>
>> And when any entity is deleted then the ArtifactStore can make a call
>> to delete all blobs where blobId starts with doc.id
>>
>> Doing it for every delete may add overhead as only action types are
>> making use of attachments currently. So here ArtifactStore may need to
>> "interpret" the entityType of the document being deleted and see if
>> its action then also make a delete call for attachment
>>
>> Any suggestion on which approach to take here? Proposal #B requires no
>> change in OpenWhisk and can be done in custom implementation
>>
>> Chetan Mehrotra
Re: ArtifactStore Attachment support and deletions
Posted by Rodric Rabbah <ro...@gmail.com>.
How about a hybrid approach?
The low level interface introduces delete attachment and the whisk store for whisk actions overrides del to manage the attachment?
I haven’t tinkered with the code to try this out.
-r
> On Feb 23, 2018, at 3:27 AM, Chetan Mehrotra <ch...@gmail.com> wrote:
>
> I am working on a custom ArtifactStore implementation. While
> implementing the support for attachments it appears there is api to
> add and read but no api to delete an attachment.
>
> This works fine for current CouchDB store as attachment lifecycle is
> tied to document to which the attachment is being attached i.e. if
> that document is deleted then all attached documents are also removed.
>
> However for setups where the attachments are stored in a separate
> Blob/Object storage it needs to be explicitly handled.
>
> Proposal A - Explicit delete call
> ----------------------------------------------
>
> Add a new api for deleting attachment
>
> ArtifactStore#deleteAttachment(doc: DocInfo, name: String)
>
> This api is invoked in addition to ArtifactStore#del say in
> WriteOps#deleteEntity and thus ensure that any related attachments are
> also removed when the owning entity is removed
>
>
> Proposal B - Implicit delete
> ---------------------------------------
>
> Most Blob storage services allow querying and deleting by prefix in
> blob id. So while storing the attachment the BlobId can be set to
> doc.id + "/" + attachmentName
>
> And when any entity is deleted then the ArtifactStore can make a call
> to delete all blobs where blobId starts with doc.id
>
> Doing it for every delete may add overhead as only action types are
> making use of attachments currently. So here ArtifactStore may need to
> "interpret" the entityType of the document being deleted and see if
> its action then also make a delete call for attachment
>
> Any suggestion on which approach to take here? Proposal #B requires no
> change in OpenWhisk and can be done in custom implementation
>
> Chetan Mehrotra