Depends on D4324
linear task: https://linear.app/comm/issue/ENG-1288/properly-handle-the-dynamodb-item-size-limit
Adding the same limit as in the previous diff, here, in tests.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| services/commtest/tests/lib/tools.rs | ||
|---|---|---|
| 24–27 | Why do we use a function here? | |
| services/commtest/tests/lib/tools.rs | ||
|---|---|---|
| 24–27 | I wrapped this into a function because I had problems with having it as a variable. const will not work because of the as_u64 which is done in the runtime. | |
| services/commtest/tests/lib/tools.rs | ||
|---|---|---|
| 24–27 | Sure, const won't work as this value can't be computed in compile time, but maybe we can use let - which is also immutable | |
| services/commtest/tests/lib/tools.rs | ||
|---|---|---|
| 24–27 | let will not work for the global vars like this. Neither will static (same errors as const) | |
| services/commtest/tests/lib/tools.rs | ||
|---|---|---|
| 24–27 | I've found a stack question https://stackoverflow.com/questions/42743507/global-constant-initialized-at-runtime-in-rust where someone suggests to use http://rust-lang-nursery.github.io/lazy-static.rs/lazy_static/index.html lazy_static macro. Could you give it a try? | |
Comment Actions
In an ideal world, the diff reviewer does not end up having to do research like that – it's on the diff author to Google and figure out best practices in response to a request by the diff reviewer
Comment Actions
I think it would be a lot better to use lazy_static from the beginning instead of introducing a function and then replacing it with a static. Is there a reason behind choosing the opposite strategy?