You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Henceforward a create event is storage.content.new and remove event is storage.content.deleted.
Currently, there are three scenarios where consecutive remove and create events are sent with no way of differentiating between the following cases:
An object is removed and a new one is created.
An object is replaced (no object removal call was issued from a client)
A new object chunk is written.
For example, this is an example of a create event. In all above cases, the fields are equal (except size and mtime). Interestingly, ctime is also unchanged in case 2, although it is technically a new object with a new ctime. Is this a bug or intented?:
For our use case, we need to somehow differentiate between all cases. As this is a feature idea, we suggest the following changes to the event interface for the above cases:
An object is removed and a new one is created. : Send one remove and one create request (no change required as it is current functionality).
An object is replaced (no object removal call was issued from a client) : Either send a create event with a specific flag (alternatively change ctime) or send a storage.content.update event, which modify ctime, mtime, and size.
A new object chunk is written. : Since only the chunk is modified and not the whole object replaced on each write, consecutive remove and create events do not seem approriate for this case. Perhaps storage.content.update could be used here as well, or alternatively use storage.chunk.new to reflect the size and mtime update of the object.
I am aware that such changes might not be possible due to how OpenIO is processing the events itself or due to backwards compatibility, however, if there is another solution to this issue, it would be very useful to us.
STEPS TO REPRODUCE
Follow above described cases
The text was updated successfully, but these errors were encountered:
As you pointed out, it is not possible (or hard) to know which operation triggered the event. For OpenIO SDS internal operations, we did not need to distinguish them.
I see two possible evolutions:
Create new types of events for object overwrite, update and truncation, which could include both contents of storage.content.new and storage.content.deleted events.
Keep the existing events, but add a new field telling which kind of operation triggered the event emission. This solution is easier to implement, and does not break compatibility.
Hi Florent, thanks for the detailed reply and considering the change!
I don't think it is necessary to create new types of events. Keeping the existing events and adding some additional information, as you suggested in Option 2, is sufficient and would help significantly.
ISSUE TYPE
COMPONENT NAME
OpenIO event interface
SDS VERSION
SUMMARY
Henceforward a create event is
storage.content.new
and remove event isstorage.content.deleted
.Currently, there are three scenarios where consecutive remove and create events are sent with no way of differentiating between the following cases:
For example, this is an example of a create event. In all above cases, the fields are equal (except
size
andmtime
). Interestingly,ctime
is also unchanged in case 2, although it is technically a new object with a newctime
. Is this a bug or intented?:For our use case, we need to somehow differentiate between all cases. As this is a feature idea, we suggest the following changes to the event interface for the above cases:
ctime
) or send astorage.content.update
event, which modifyctime
,mtime
, andsize
.storage.content.update
could be used here as well, or alternatively usestorage.chunk.new
to reflect thesize
andmtime
update of the object.I am aware that such changes might not be possible due to how OpenIO is processing the events itself or due to backwards compatibility, however, if there is another solution to this issue, it would be very useful to us.
STEPS TO REPRODUCE
Follow above described cases
The text was updated successfully, but these errors were encountered: