3 ms·
Sounds like the source of truth for the enum members may have been in the database. (But yes, exhaustiveness checking for sum types is a great feature.)
by matt_kantor 2y ago
Sounds like the source of truth for the enum members may have been in the database.
(But yes, exhaustiveness checking for sum types is a great feature.)
- galangalalgol 2y agoThe only db work I've done in rust required a recompile if the db schema changed, or even the specific queries your program used, because the rust types got generated from the schema. So in those cases the db change would have driven a rust type change and rust would have verified exhaustive handling.
- etherealG 2y agoDb changes are generally at runtime, how would you recompile rust code during the save of the data to the db? How do you rollback the change if a compile fails? How do you add the necessary code to handle new cases of the enum but not have it present in the db? This is amazingly interesting to me, would love to know more.
- avg_dev 2y agoMaybe a code gen layer that generates rust types from a db schema. I don’t know rust but have seen those in other languages. I could see a DB enum type corresponding to a language specific enum type and then the language rules applying. I do think this is a level of indirection myself; if the generated code was perfect and always in sync, that would be one thing, but by definition it is not the case.