github.com/voedger/voedger@v0.0.0-20240520144910-273e84102129/design/projectors/idempotency.md (about) 1 ### Terms 2 - Idempotent view 3 - The view which can not be *updated* twice with the same event 4 5 ### Motivation 6 - As a developer, I want that my views are idempotent out of the box so that I shouldn't take care of this in my extensions 7 8 ### Principles 9 - All views are idempotent by design. 10 - Idempotency is only checked for *Update* intents of the extensions 11 - No need to check it for *Insert* operations: there's always CanExist / MustNotExist check before Insert operation in the extensions 12 13 ### Implementation 14 - An additional field is added by core to store last applied offset to all views 15 - Existing views: 16 - views which does not have this field so once added it will store zero for existing values. Engine should take this into account. 17 - view having "offs" field already: check that WLog offset is stored 18 - should be possible to rename safely field name from "offs" to some different name 19 - StateStorage uses this field: 20 - To automatically handle the idempotency on every *update* operation 21 - Update isn't applied when previous value is already updated with same event in before 22 - StateStorage must know the WLog offset of the current event 23 - To automatically fill the offset value for *create* operations 24 - To send N10n then this field is updated 25 - Notes regarding the WasmEngine: 26 - WasmEngine receives number of intents from ProxyWasm, each has key and value. Those intents which have last applied offset same or higher than the current WLog offset, are dropped 27 - Those intents which have no offset filled, are provided with the current WLog offset 28 29 ### Current Solution 30 - Developer manually controls the idempotency. 31 - N10n is sent by StateStorage when the field "offs" is updated. 32 - The same field "offs" is used to control idempotency and sending N10n 33