Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Lars Wirzenius <liw@liw.fi>
Sponsored-by: author
|
|
The test passes. We create a FilesystemEntry with a length field
containing u64::MAX, store that into a generation, and read it back.
This works. The entry is serialised into JSON for storing in SQLite,
and this proves we can handle any u64 value in an entry. serde_json
deals with it fine, and we don't need to worry about it.
Sponsored-by: author
|
|
This is a breaking change, but allows to store the largest signed
64-bit integers in SQLite and get it back.
Sponsored-by: author
|
|
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
|
|
This makes the code clearer and allows for catching more errors,
albeit at runtime, such as using the wrong column name.
Sponsored-by: author
|