How to Get Foreign Keys Horribly Wrong

(hakibenita.com)

60 points Bogdanp | 1 comments | 15 Jul 25 11:36 UTC | HN request time: 0s | source

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 #

teaearlgraycold ◴[18 Jul 25 19:32 UTC] No.44608878[source]▶

>>44608805 #

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 #

cjs_ac ◴[18 Jul 25 19:47 UTC] No.44609025[source]▶

>>44608878 #

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 #

1. teaearlgraycold ◴[18 Jul 25 20:43 UTC] No.44609622{3}[source]▶

>>44609025 #

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.

↑