2 ms·

I might just be naive, or you and I worked at places where different practices were implemented, but... ...should a DBA really SSH into the machine and run arb

I might just be naive, or you and I worked at places where different practices were implemented, but... ...should a DBA really SSH into the machine and run arbitrary schema changes willy-nilly? In my ideal workflow, the database admin should write a migration script, open a PR, get it reviewed and merged, released to a staging environment via CI/CD, and when nothing blows up, a CI/CD process should run the schema changes on production. At any point, you can track down how your database schema looks like, and nowhere in the process I need to worry about the unfortunate case of "oh, yeah, that table, yeah that table looks completely different because Tom was firefighting yesterday night, we have no idea what he did or when, but hopefully we didn't lose any data". In the environment that I described, sqlx fits in perfectly (and the DBA would probably get a good talking to for goofing around on live systems in ways that leaves the whole team in the dark, but that's a different issue)

epcoa 3y ago
I’m not sure what part of “I get why this shit is useful” is unclear. The original comment made a statement about the guarantees static typing and the limitations of those guarantees, the response while making some tangentially valid points called it a “funny example” as if it ran counter to those limitations. But it doesn’t, that’s all. In this example you are still doing the same compile time verification at runtime. It’s useful, but it’s not making the same type of guarantee. “ should a DBA really SSH into the machine and run arbitrary schema changes willy-nilly” Such a straw man. No matter what the process is, mistakes happen, organizational communication breaks down, environment variables don’t get set, there are thousands of reasons your database schema won’t be as expected that have nothing to do with a rogue DBA. Who said the DBA in my example was acting willy-nilly? Maybe they are following the process. That doesn’t make the static compiled artifacts just disappear. You can put all kinds of additional guards in. These are mostly outside the type system. Do you believe in your process so thoroughly that you would disable any runtime type checking in sqlx if it had the option? (it doesn’t, for what I thought should be obvious reasons).

epcoa 3y ago

I’m not sure what part of “I get why this shit is useful” is unclear. The original comment made a statement about the guarantees static typing and the limitations of those guarantees, the response while making some tangentially valid points called it a “funny example” as if it ran counter to those limitations. But it doesn’t, that’s all. In this example you are still doing the same compile time verification at runtime. It’s useful, but it’s not making the same type of guarantee. “ should a DBA really SSH into the machine and run arbitrary schema changes willy-nilly” Such a straw man. No matter what the process is, mistakes happen, organizational communication breaks down, environment variables don’t get set, there are thousands of reasons your database schema won’t be as expected that have nothing to do with a rogue DBA. Who said the DBA in my example was acting willy-nilly? Maybe they are following the process. That doesn’t make the static compiled artifacts just disappear. You can put all kinds of additional guards in. These are mostly outside the type system. Do you believe in your process so thoroughly that you would disable any runtime type checking in sqlx if it had the option? (it doesn’t, for what I thought should be obvious reasons).