←back to thread

How to Get Foreign Keys Horribly Wrong

(hakibenita.com)
60 points Bogdanp | 7 comments | 15 Jul 25 11:36 UTC | HN request time: 0.001s | source | bottom
Show context
cogman10 ◴[18 Jul 25 19:25 UTC] No.44608805[source]▶
This sort of thing hasn't really done much to make me like ORMs.

It seems like a lot of code to generate the tables in the first place and you STILL need to read the output scripts just to ensure the ORM isn't generating some garbage you didn't want.

That seems like a lot of extra effort when a simple migration service (such as liquibase) could do the same work running SQL directly. No question on "which indexes are getting created and why". No deep knowledge of Django interactions with sql. Instead, it's just directly running the SQL you want to run.

replies(2): >>44608878 #>>44609291 #
1. teaearlgraycold ◴[18 Jul 25 19:32 UTC] No.44608878[source]▶
I would say automatic migration generation isn’t a necessary or particularly important part of an ORM. ORMs are there to map your database relational objects to your client language’s objects.
replies(3): >>44609025 #>>44609034 #>>44609225 #
2. cjs_ac ◴[18 Jul 25 19:47 UTC] No.44609025[source]▶
I think the person you're replying to is arguing for using some sort of database migration library without using an ORM library. It's the same position I came to recently.
replies(1): >>44609622 #
3. Tostino ◴[18 Jul 25 19:49 UTC] No.44609034[source]▶
I'd call it an anti-feature for most long-lived projects that will end up needing migrations through its lifetime.

I go the liquibase route for migrations, and just use the mapping portion of any ORM.

4. pphysch ◴[18 Jul 25 20:08 UTC] No.44609225[source]▶
Most(?) devs nowadays are introduced to database migration tools as a DX feature.

"Wow, 1-2 command and my app and database are in sync!"

In reality, migration tools are 100% about data loss prevention.

If you do not care about data loss, updating your schema is trivial, just drop everything and create. Dev environments should be stateless anyways, using separate data "fixtures" when needed.

Data loss itself is a highly nuanced topic. Some data is replaceable, some might be protected in a separate store. So I agree that ORMs should challenge the assumption that automatic migration tools need to be part of their kitchen sink.

replies(2): >>44609647 #>>44611178 #
5. teaearlgraycold ◴[18 Jul 25 20:43 UTC] No.44609622[source]▶
Yes but they seem to have switched because they didn’t like ORM-generated migration code. I think that’s a bad reason to switch because it wasn’t an important part of ORMs in the first place. Basically, I want to know why they were even using ORMs before.

I don’t want to go without an ORM because I’ll end up making one ad-hoc anyway. I’m not going to do work on raw tuples in my application code.

6. teaearlgraycold ◴[18 Jul 25 20:46 UTC] No.44609647[source]▶
I like that they provide the basic structure of how to apply yet unseen migrations. But they don’t need to generate the SQL at all. You quickly learn to never trust the generated code. It always needs to be manually reviewed.
7. wagwang ◴[18 Jul 25 23:58 UTC] No.44611178[source]▶
The ORM auto migration tools are a 100% a DX feature. Obviously any serious application will have complicated migrations that outgrow the generated sql; doesn't mean its not a nice to have feature for quick iteration.