4 ms·

Databases are a funny example. One of the most popular database libraries in rust is sqlx, which will typecheck your SQL against a running database. Of course i

Databases are a funny example. One of the most popular database libraries in rust is sqlx, which will typecheck your SQL against a running database. Of course it can't prove that your SQL does what you want it to, but it goes very far in ensuring that the database won't outright reject your queries and that types are respected.

jeremyloy_wt 3y ago
Oh is that what the online/offline stuff in their docs mean? I’ve never heard of that technique being used before, that’s really interesting
- wongarsu 3y ago
  Exactly. Normally it will use whatever database you put in your DATABASE_URL environment variable (or .env), but you can run `cargo sqlx prepare` to save the metadata in a bunch of json files to enable offline development or if you CI environment doesn't have a database instance. However you will need to update this every time you change a SQL query. I find it more convenient to just develop in online mode against a local database.
epcoa 3y ago
Does it also plant a trojan in the DB for the next time the DBA attempts to change the schema? I get why this shit is useful but it really doesn’t respond to the parent comment - you’re still getting runtime checks.
- serial_dev 3y ago
  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).

jeremyloy_wt 3y ago

Oh is that what the online/offline stuff in their docs mean? I’ve never heard of that technique being used before, that’s really interesting

wongarsu 3y ago
Exactly. Normally it will use whatever database you put in your DATABASE_URL environment variable (or .env), but you can run `cargo sqlx prepare` to save the metadata in a bunch of json files to enable offline development or if you CI environment doesn't have a database instance. However you will need to update this every time you change a SQL query. I find it more convenient to just develop in online mode against a local database.

epcoa 3y ago

Does it also plant a trojan in the DB for the next time the DBA attempts to change the schema? I get why this shit is useful but it really doesn’t respond to the parent comment - you’re still getting runtime checks.

serial_dev 3y ago
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).