...
- For locally stored data, reads will be served with surrogate timestamp -1 (semantics is unknown).
- On put, data will be stored using the new format.
- Key-Value store: new
RocksDBWithTimestamp
store is usesused. To isolate old and new format, we use two column families. We perform dual put/get operation in new and old column family to lazily upgrade all data from old to new format. - Window/session store: existing segments will use old format and new segments will be created with the new format.
...
Simple rolling bounce upgrade is sufficient. For PAPI uses, nothing changes at all. For DSL users, the internal RocksDBWithTimestampStore
(as one example) will upgrade the store data lazily in the background. Only if users provide a custom XxxByteStoreSupplier
no upgrade happens (but users can opt-in implementing RecordConverter
interface) but the old format is kept. We use a proxy store that removes/add adds timestamp on read/write.
To keep interactive queries feature compatible, the new XxxWithTimestampStores
can be queried with and without timestamp. This is important for DSL users, that might query a store as KeyValueStore
while the DSL switches the store internally to a KeyValueWithTimestampStore
. Thus, we allow to query a KeyValueWithTimestampStore
with queryable story type "key-value" and remove the timestamp under the hood on read. Compatibility for window/session stores are handled similarly.
...