If the PreviousClock is undefined, and the store is native the previous clock is not fetched, and is instead assumed to be the same as the passed clock.
https://github.com/martinsumner/kv_index_tictactree/blob/master/src/aae_controller.erl#L648-L661
There are two scenarios where the previous clock may be undefined:
- On a rehash
- On a fast-write-path put (with no read before write)
The latter part cannot happen in a native store in Riak. This is because read-before-write puts are disabled for a backend with the 2i capability (and IndexBackend).
In either case fetching the previous object clock that doesn't make sense, as the database may have moved on since the aae_put was cast. The clock might now be a future clock, a present clock or a previous clock.
The implemented behaviour is probably the right behaviour - but it should be more obvious and explicit that native mode will not do the potentially expected thing when run in native mode, rather than mysteriously doing something inert.
If the PreviousClock is undefined, and the store is
nativethe previous clock is not fetched, and is instead assumed to be the same as the passed clock.https://github.com/martinsumner/kv_index_tictactree/blob/master/src/aae_controller.erl#L648-L661
There are two scenarios where the previous clock may be undefined:
The latter part cannot happen in a native store in Riak. This is because read-before-write puts are disabled for a backend with the 2i capability (and IndexBackend).
In either case fetching the previous object clock that doesn't make sense, as the database may have moved on since the aae_put was cast. The clock might now be a future clock, a present clock or a previous clock.
The implemented behaviour is probably the right behaviour - but it should be more obvious and explicit that native mode will not do the potentially expected thing when run in native mode, rather than mysteriously doing something inert.