technology

24104 readers

482 users here now

On the road to fully automated luxury gay space communism.

Spreading Linux propaganda since 2020

Rules:

1. Obviously abide by the sitewide code of conduct. Bigotry will be met with an immediate ban
2. This community is about technology. Offtopic is permitted as long as it is kept in the comment sections
3. Although this is not /c/libre, FOSS related posting is tolerated, and even welcome in the case of effort posts
4. We believe technology should be liberating. As such, avoid promoting proprietary and/or bourgeois technology
5. Explanatory posts to correct the potential mistakes a comrade made in a post of their own are allowed, as long as they remain respectful
6. No crypto (Bitcoin, NFT, etc.) speculation, unless it is purely informative and not too cringe
7. Absolutely no tech bro shit. If you have a good opinion of Silicon Valley billionaires please manifest yourself so we can ban you.

founded 5 years ago

MODERATORS

context@hexbear.net

SexUnderSocialism@hexbear.net

gaycomputeruser@hexbear.net

Wakmrow@hexbear.net

SwitchyandWitchy@hexbear.net

ORMs are stupid. Get rid of them. (hexbear.net)

submitted 2 months ago* (last edited 2 months ago) by PorkrollPosadist@hexbear.net to c/technology@hexbear.net

13 comments fedilink hide all child comments

SQL is good actually. Using your database system to define your data model along with all of its constraints is much better than just scribbling out some Rust/TypeScript/Go datatypes and shitting them out into a schema with a new database migration every fucking commit.

Your SQL application does not need to be portable. You don't need an over-engineered rube-goldberg solution where you can slot out OracleDB for SQLite for fucking CSV documents. Your code SHOULD be ANSI/ISO standard, but it just needs to run on PostgreSQL. PostgeSQL is portable.

Thanks for coming to my TED talk.

you are viewing a single comment's thread
view the rest of the comments

[–] JakenVeina@midwest.social 1 points 2 months ago

SQL is good actually.

Who says it's not?

Using your database system to define your data model along with all of its constraints...

This is what you're doing with or without an ORM. It's just a question of which language you're doing it it.

...with a new database migration every fucking commit.

Again, this is what you're doing with or without an ORM. When you have business-layer changes that require data schema changes, orchestrating those schema changes in a way that preserves data is a thing you have to do. If you're not using an ORM and associated tooling, you're doing it by hand.

You don’t need an over-engineered rube-goldberg solution where you can slot out OracleDB for SQLite for fucking CSV documents.

ORMs are NOT intended to make the database layer something you can swap out on a whim. That's a pretty common belief, but it's a fallacy.