This diff introduces the SyncedMetadata store ops spec. This will be used process operations on the integrity store
Depends on D11414
Details
Details
- Reviewers
kamil ginsu atul - Commits
- rCOMM205d98818c41: [lib] introduce SyncedMetadata store spec
flow check. Functionality tested later in stack
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| lib/ops/synced-metadata-store-ops.js | ||
|---|---|---|
| 2 ↗ | (On Diff #38393) | can be removed |
| 10 ↗ | (On Diff #38393) | nit: in other files there is no additional line after this comment |
| 40–43 ↗ | (On Diff #38393) | don't think we need this - now this is the same as ReplaceSyncedMetadataEntryOperation. I guess this could simplify a lot of the code below. |
| 89–104 ↗ | (On Diff #38393) | this could just return ops - this code is not changing anything |
| lib/ops/synced-metadata-store-ops.js | ||
|---|---|---|
| 40–43 ↗ | (On Diff #38393) | Debated on whether I should include this and might have made the wrong judgement of including it in case we ever changed the payload type. Will remove in my next rebase |
| lib/ops/synced-metadata-store-ops.js | ||
|---|---|---|
| 40–43 ↗ | (On Diff #38393) | I'm assuming this also means that we can replace the usage of ClientDBSyncedMetadataStoreOperation with SyncedMetadataStoreOperation |
| lib/ops/synced-metadata-store-ops.js | ||
|---|---|---|
| 40–43 ↗ | (On Diff #38393) | Scratch that. Might be a good idea to keep the ClientDBSyncedMetadataStoreOperation type to keep implementation of BaseStoreOpsHandlers and future usages clear as we have to implement convertOpsToClientDBOps and translateClientDBData anyway. |
| lib/ops/synced-metadata-store-ops.js | ||
|---|---|---|
| 10 ↗ | (On Diff #38393) | Got it. I just noticed I did the same with // SQLite types as well so will fix that too. |
| lib/ops/synced-metadata-store-ops.js | ||
|---|---|---|
| 11 ↗ | (On Diff #38447) | I believe we typically exclude the entity type in the operation.type I think they're usually like replace, remove, remove_all, etc. |
| 86 ↗ | (On Diff #38447) | We'll want to make sure on the C++ side we're always returning some sort of array. Specifically we should return empty array instead of null/undefined if there are no entries |
| lib/ops/synced-metadata-store-ops.js | ||
|---|---|---|
| 86 ↗ | (On Diff #38447) | |
| 40–43 ↗ | (On Diff #38393) | translateClientDBData will still have to be implemented because it converts the array to an object. convertOpsToClientDBOps at the current state looks weird because it does nothing - just returns param but types are different which looks confusing. Not sure why keeping the same type defined twice with two different names is better but I don't feel strongly - leaving this up to you |
| lib/ops/synced-metadata-store-ops.js | ||
|---|---|---|
| 11 ↗ | (On Diff #38447) | I just had a look at all the store-ops in the lib/ops folder. Seemingly, the only file that uses plain replace, remove, remove_all as its types is thread-store-ops.js while the rest include the entity. Ex. export type ReplaceKeyserverOperation = {
+type: 'replace_keyserver',
+payload: { +id: string, +keyserverInfo: KeyserverInfo },
}; |