summaryrefslogtreecommitdiff
path: root/src/dbgen.rs
AgeCommit message (Collapse)AuthorFilesLines
2022-05-03refactor: add a type for plain integers we store in a databaseLars Wirzenius1-3/+3
This will make it easier to change later, if need be. We may want to do that for various reasons, such as to save space. We may also want to change things to only use integer types that SQLite can handle: u64 is currently not well handled by our database layer. However, as this is a refactor, there's no change or fix to that. FileId is now explicitly a database integer. This doesn't break anything, for now, as the underlying integer type is still u64. Also, change a couple of places where it will matter if DbInt changes away from u64, and disable warnings for harmless conversions that may cause warnings depending on what type DbInt has. Sponsored-by: author
2022-04-16feat: use one checksum for all chunks in a backupLars Wirzenius1-8/+32
When making a backup, use the same checksum for any chunks it re-uses or creates. This is for performance: if we allowed two checksums to be used, we would have to compute the checksum for a chunk twice, and potentially look up both on the server. This is just a lot of work. Instead, we use only one. The trade-off here is that when (not if) the user wants to switch to a new checksum type, they'll have to do a full backup, uploading all their data to the server, even when it's already there, just with a different checksum. Hopefully this will be rare. Full backups always use the built-in, hardcoded default checksum, and incremental backups use whatever the previous backup used. The default is still SHA256, but this commit add code to support BLAKE2 if we decide to switch that as a default. It's also easy to add support for others, now. BLAKE2 was added to verify that Obnam can actually handle the checksum changing (manual test: not in the test suite). I don't think users need to be offered even the option of choosing a checksum algorithm to use. When one cares about both security and performance, choosing a checksum requires specialist, expert knowledge. Obnam developers should choose the default. Giving users a knob they can twiddle just makes it that much harder to configure and use Obnam. If the choice Obnam developers have made is shown to be sub-optimal, it seems better to change the default for everyone, rather than hope that every user changes their configuration to gain the benefit. Experience has shown that people mostly don't change the default configuration, and that they are especially bad at choosing well when security is a concern. (Obnam is free software. Expert users can choose their checksum by changing the source code. I'm not fundamentally limiting anyone's freedom or choice here.) Users can switch to a new default algorithm by triggering a full backup with the new "obnam backup --full". Sponsored-by: author
2022-03-20feat: allow user to choose backup schema version for new backupsLars Wirzenius1-45/+462
The way this is currently implemented resulted in a lot of code duplication in src/generation.rs. This should be refactored later. My first attempt to do it by adding a trait for a schema variant failed. Sponsored-by: author
2022-03-06refactor: use new database abstraction for generationsLars Wirzenius1-5/+12
Sponsored-by: author
2022-03-06refactor: add a high level database abstraction for backupsLars Wirzenius1-0/+320
Sponsored-by: author