If you absolutely can’t make it work, a single Option at least would be more correct as all the fields on the inner struct would be optional together.
Wait really? If I wrap a struct in Option it makes all the fields optional?
Good to know that you think the Into approach seems better. Part of the purpose of this thread is to just gauge what's the better way to do this in Rust. Do you know what "separating the types with Into" would look like?
I'd provide more code but it's a mess and full of old commented-out code. Your examples are perfect! combining the DB fields into it's own struct is something I hadn't thought of... and I totally get why having a bunch of options sitting in the Army struct would be problematic. I'm really excited about rust for moving these sorts of errors to compile time.
The INTO example seems great too. I'm ok with the performance hit of cloning for now... lifetimes and pointers feel like a tier above where am at with my rust skills, and I'll circle back to get a better handle on them later.
One question about the INTO example... I always hear it's better to just implement FROM and get INTO for free. Does that not make sense for my use case? If I did it, would it look something like:
impl From<ArmyWithDbProps> for Army { fn from(self) -> ArmyWithDbProps { self.armyWithDbProps } }