Re: ArtifactStore Attachment support and deletions

2018-02-27 Thread Chetan Mehrotra
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  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  
>> 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

2018-02-23 Thread Rodric Rabbah
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  
> 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