cljoly / rusqlite_migration / 14021342810 / 1
94%
master: 95%

LAST BUILD BRANCH: dependabot/cargo/tokio-1.52.2
DEFAULT BRANCH: master
Ran
Files 4
Run time 0s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 93.226% (-1.4%) from 94.649%
14021342810.1

Pull #241

github

cljoly 
fix: return explicit errors when user_version is wrong

Prior to this change, if we read a negative [user version][uv_offset],
it will be converted to a `usized`. This often results in high numbers,
that are outside the range of defined migrations. This would thus likely
return a “migration out of bounds”-type error.

This fixes this, explicitly checking that the conversion to `usize` goes
well and returning an error if not.

While we are touching this, also specify the maximum number of
migrations supported. This should make implementing
https://github.com/cljoly/rusqlite_migration/issues/170 easier.

Alternative options
-------------------

I have considered using a `i32` everywhere instead (since we are about
to break compatibility with a 2.0 version), but then I have to convert
back and forth with `usize` in multiple places. This is error prone.
Another drawback is that we won’t get compile time errors for negative
numbers (`i32` is a signed type) and that is a more likely mistake than
passing a number of migrations higher than about 2 billion.

Unfortunately, there is no Rust type in the standard library that has
both of those constraints:
* >= 0
* <= `i32::MAX`
(u32 comes to mind, but `u32::MAX` is still too big).

Thus it seems easier to just stick with the standard library type and
return an error if the user passes numbers higher than i32::MAX. Using a
custom type in `to_version` seems excessively verbose and has almost no
benefits: if the user is to create a value in this custom type from a
`i32` or a `usize`, they still have to handle corner cases like negative
numbers or values higher than `i32::MAX`.

[uv_offset]: https://www.sqlite.org/fileformat.html#user_version_number
Pull Request #241: fix: return explicit errors when user_version is wrong

289 of 310 relevant lines covered (93.23%)

6.21 hits per line

Source Files on job 14021342810.1