Closed 0x009922 closed 2 months ago
since they are all technically limited to the maximum vec size in Iroha, which is
usize
, which is commonly represented asu64
in the data model.
that is the hard upper limit, we can choose to make it tighter. Using a u64
for fetch size is unnecessary, especially when you consider that MAX_FETCH_SIZE = 10000
that is the hard upper limit, we can choose to make it tighter.
I am fine either way, just want to make it consistent.
Using a
u64
for fetch size is unnecessary, especially when you consider thatMAX_FETCH_SIZE = 10000
I see, maybe then make it even smaller, like u16
?
@BAStos525
@mversic as was discussed, let's keep u64
.
Tests seem to work on my machine.
Context
There are some minor inconsistencies within query parameters (pagination, fetch size, sorting):
iroha_data_model
as a libraryu32
, while pagination offset isu64
. It doesn't make sense, since they are all technically limited to the maximum vec size in Iroha, which isusize
, which is commonly represented asu64
in the data model.Option<NonZero<u64>>
, whereNone
value doesn't give any additional meaning and is just treated as zero, which is also a default value foru64
.Solution
u64
/NonZero<u64>
everywhereu64
instead ofOption<NonZero<u64>>
offset
, second islimit
(affects ordering in the constructor)Review notes (optional)
Checklist
CONTRIBUTING.md
.