Skip to content

Conversation

@michaeldjeffrey
Copy link
Contributor

#1068 is a big change.
This PR is a smaller subset that I think is still good while the larger structure of file-store is talked about.

  • Remove MsgBytes
    • it added unnecessary restriction to file-store. Outside crates wanting to use outside protobuf structs could not because of the orphan rule.
    • Remove unused deps
      • csv and humantime-serde
  • CLI commands return anyhow::Result instead of file_store::Result
    • This allows us to drop some err variants that the lib does not use, mainly serde_json::Error
  • Use prost::Message instead of helium_proto::Message, a nicer separation of deps
  • Generalize Into<FIleInfo> for anything that can turn itself into a string
    • Stronger decoupling from FileType for FileInfo
  • Remove unused err variants
    • file_store::Error::JoinError used by unused start() function (also removed)
    • file_store::Error::Config used when constructing file_store::Settings, but not in the library code path
    • file_store::Error::Shutdown unused

anything that can be turned into a string can now become a FileType.
Attempting to remove the dependency between FileInfo and FileType.
It’s an extra layer of indirection that makes it hard to use other proto
types with file-store.

Originally MsgBytes had to be implemented for any type that wanted to 
use FileStoreWriteExt and every type had to have a manual implementation
cecause of our lack of ability to provide a blanket impl for 
prost::Message. Almost literally everything implements prost::Message.

We don’t lose any type safety because we still type our FileClients and 
the like with the protobuf type we expect to be writing.
trying to remove the hard dep on helium-proto for lib specific code.
This allows us to remove some unneeded err variants from 
file-store::Error.
file-store lib does not encode anything to JSON. If this err is needed 
it’s at the application level.
file-store the lib does not make clients from it’s settings, that all 
happens at the application level. The config::ConfigError can be mapped 
at that level.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant