ref(api): Move chunk data types to submodule #2086
Conversation
| use serde::{Deserialize, Deserializer}; | ||
|
|
||
| #[derive(Debug, Clone, Copy, Ord, PartialOrd, Eq, PartialEq, Default)] | ||
| pub enum ChunkCompression { |
There was a problem hiding this comment.
driveby question: how much effort would it be to add zstd compression to the whole workflow?
There was a problem hiding this comment.
I am not sure – have not worked too extensively with compression in the CLI yet.
What would be the benefit of adding zstd? Do we have any docs written about it?
There was a problem hiding this comment.
no, we don’t have any docs on that.
and zstd is pretty much the best choice if you want to trade compression ratio for resource usage.
There was a problem hiding this comment.
Ok, we should probably investigate how much effort this would be, will open an issue
- Create a new `data_types` submodule under the `api` module. - Crate a `chunking` submodule under the `data_types` module. - Move all data types related to chunking from `src/api/mod.rs` to the `chunking` submodule, splitting their definitions further into submodules under `chunking`. Ref #2077
szokeasaurusrex
force-pushed
the
szokeasaurusrex/data-types
branch
from
ffaf458
to
b37ff70
Compare
|
@loewenheim Fair enough, I guess it comes down to personal preference a bit. My reasoning is that each of these new modules has now a distinct responsibility; all code in a single module is closely related. When files get long, I have difficulty keeping track of everything in the file. It is much easier for me to work with many small files where I can clearly wrap my head around each one |
data_typessubmodule under theapimodule.chunkingsubmodule under thedata_typesmodule.src/api/mod.rsto thechunkingsubmodule, splitting their definitions further into submodules underchunking.This PR only moves existing code, adding
modandusestatements and adjusting visibility as needed. No other modifications were made.Ref #2077