@cloudbitmaps/roaring 0.11.1 → 0.11.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/PRIVACY.md +5 -3
- package/dist/bin/export-segments.js.map +2 -2
- package/dist/index.d.ts +3 -2
- package/dist/index.js.map +2 -2
- package/package.json +2 -2
package/PRIVACY.md
CHANGED
|
@@ -123,15 +123,17 @@ after it returns, and re-run any erasure a rollback interrupted.
|
|
|
123
123
|
|
|
124
124
|
### One process, and the rest of your fleet
|
|
125
125
|
|
|
126
|
-
Erasure and crypto-shred are **immediate in storage and immediate in the store whose verb performed them
|
|
127
|
-
|
|
126
|
+
Erasure and crypto-shred are **immediate in storage and immediate in the store whose verb performed them**, for
|
|
127
|
+
every read that starts after the verb returns. A read already in progress in that store can still yield an erased id
|
|
128
|
+
from a chunk it had requested before the verb ran: up to 8 chunks for `iterate` and `count`, and up to `concurrency`
|
|
129
|
+
keys for a combine. They are not immediate in any *other* store, in the same process or another, and this library ships nothing that could
|
|
128
130
|
make them so — there is no daemon, no bus, and no connection between two stores that happen to point at the same
|
|
129
131
|
bucket.
|
|
130
132
|
|
|
131
133
|
| | when the id stops being readable |
|
|
132
134
|
|---|---|
|
|
133
135
|
| storage | on return — the generation holding it is deleted, or the wrapped DEK is removed from the segment's current registry row (a crypto-shred is complete once no retained copy of that row holds it, or every KEK that wrapped it is destroyed; see *Erasure vs. backups / WORM* below) |
|
|
134
|
-
| the store whose verb made the call (`eraseSubject`, `dropSegment`, `retireExpired`) | on return — it invalidates what it cached, and its pins then fail |
|
|
136
|
+
| the store whose verb made the call (`eraseSubject`, `dropSegment`, `retireExpired`) | on return, for every read that starts after it — it invalidates what it cached, and its pins then fail; a read already in progress there can still yield it from a chunk it had requested before |
|
|
135
137
|
| another store, with a registry and a `cache.genTtlMs` above 0 | within `cache.genTtlMs` (default 2 s), when its snapshot re-resolves, **while the registry can be read** (see below) |
|
|
136
138
|
| another store with **no registry** (a bare `IStorageDriver`), with `cache: { genTtlMs: 0 }`, or on a storage source built with **no clock** | **no bound** — only when its caches happen to let the segment go, or something tells it |
|
|
137
139
|
| a pinned handle (`seg.pin()`) in another store | **no bound** — until that store's reader cache evicts the pin's reader and its chunk cache evicts the chunks the pin decoded, or something tells it |
|