This was an idea that I wanted to implement but forgot before. We can prefix the backupID partitioning key in the log table with the userID. I think this is better because it allows us to map the log directly to the backup in the backup table (before we didn't knew the userID which is the partitioning key of the backup table). This is a quick change and we still aren't using backup service in production so I decided to implement it now. An alternative would be to add a new attribute but I prefer to keep them both in the partitioning key as they really represent a one things -> a specific backup of a given user. And if we ever need to iterate over specific user's logs we will also need to iterate over the compaction data so it wouldn't gain us anything.
Details
Details
- Reviewers
bartek - Commits
- rCOMM6b1b41cd1e3d: [backup] Namespace log id in db
Run backup integration tests.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| services/backup/src/database/log_item.rs | ||
|---|---|---|
| 108–119 ↗ | (On Diff #36239) | If you're taking (moving) the id here, are these ref/slice gymnastics still necessary? 😉 |
| services/backup/src/database/log_item.rs | ||
|---|---|---|
| 108–119 ↗ | (On Diff #36239) | split returns an iterator over &str and I don't think there is a mutable version of it, so I don't think we can get rid of the to_string calls. The &[..] is just so we can pattern match on the result. We could do it more "imperatively" but I like this approach because we directly specify that we want an array with two values. Alternatively we could use as_slice instead of &[..]. |