Summary
$server_options.max_map_value_bytes appears to be documented and tested as the in-database
override for map value byte limits, but the cached server-option table wires
SVO_MAX_MAP_VALUE_BYTES to max_list_value_bytes.
As a result, map value-size checks appear to read $server_options.max_list_value_bytes
instead of $server_options.max_map_value_bytes.
Current Source
In src/include/server.h:
DEFINE( SVO_MAX_MAP_VALUE_BYTES, max_list_value_bytes,
This likely should be:
DEFINE( SVO_MAX_MAP_VALUE_BYTES, max_map_value_bytes,
Source comments in src/include/options.h describe the intended option names:
$server_options.max_string_concat,
$server_options.max_list_value_bytes and $server_options.max_map_value_bytes
override these defaults.
Tests also create and set $server_options.max_map_value_bytes in test/tests/test_limits.rb.
Impact
Databases attempting to tune map value-size limits independently cannot use
$server_options.max_map_value_bytes as intended. The effective map limit is controlled by
$server_options.max_list_value_bytes.
This also means documentation that describes $server_options.max_map_value_bytes as the map
limit option would be misleading unless the source is fixed.
History
This appears to date back to the 2012 value-byte-limit change:
- cffcda6 added comments/constants for max_list_value_bytes and max_map_value_bytes.
- 58c6941 updated tests to use $server_options.max_map_value_bytes.
- 36c3839 added SVO_MAX_MAP_VALUE_BYTES, but mapped it to max_list_value_bytes.
- Later cleanup removed the old max_map_concat option, leaving the mapping mismatch in place.
The current tests do not catch this because they set list and map limits to the same value
through the same helper.
Suggested Fix
- Change the cached option mapping to use max_map_value_bytes.
- Add a regression test that sets max_list_value_bytes and max_map_value_bytes to different
values, then verifies map construction/enlargement follows the map-specific limit.
Summary
$server_options.max_map_value_bytes appears to be documented and tested as the in-database
override for map value byte limits, but the cached server-option table wires
SVO_MAX_MAP_VALUE_BYTES to max_list_value_bytes.
As a result, map value-size checks appear to read $server_options.max_list_value_bytes
instead of $server_options.max_map_value_bytes.
Current Source
In src/include/server.h:
DEFINE( SVO_MAX_MAP_VALUE_BYTES, max_list_value_bytes,
This likely should be:
DEFINE( SVO_MAX_MAP_VALUE_BYTES, max_map_value_bytes,
Source comments in src/include/options.h describe the intended option names:
$server_options.max_string_concat,
$server_options.max_list_value_bytes and $server_options.max_map_value_bytes
override these defaults.
Tests also create and set $server_options.max_map_value_bytes in test/tests/test_limits.rb.
Impact
Databases attempting to tune map value-size limits independently cannot use
$server_options.max_map_value_bytes as intended. The effective map limit is controlled by
$server_options.max_list_value_bytes.
This also means documentation that describes $server_options.max_map_value_bytes as the map
limit option would be misleading unless the source is fixed.
History
This appears to date back to the 2012 value-byte-limit change:
The current tests do not catch this because they set list and map limits to the same value
through the same helper.
Suggested Fix
values, then verifies map construction/enlargement follows the map-specific limit.