Live data from Hacker News

Things I learned after getting users

basementcommunity.bearblog.dev

51–60 of 155 posts

Re: Things I learned after getting users

#51
post #49
post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

> learn SQL properly. It's not that hard. Focus on it for a few weeks intensely and you've mastered it for life. Exactly the same is true of ORMs. I find most of the people who advocate "just use SQL" have a bizarre aversion to applying the same learning effort to their ORM. > I've had weekends ruined troubleshooting my "highly productive ORM layer" that nuked a production database. Whilst functionally speaking my OR…

> have a bizarre aversion to applying the same learning effort to their ORM.

SQL is a lingua franca while an ORM is specific to a stack.

If you know that you will always, say, be using SQLAlchemy on Python, then learning it well might be a good investment, but I don't find learning multiple ORMs to be a good time investment over just learning SQL. Most every stack has good, lightweight query builders.

Re: Things I learned after getting users

#52
post #49
post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

> learn SQL properly. It's not that hard. Focus on it for a few weeks intensely and you've mastered it for life. Exactly the same is true of ORMs. I find most of the people who advocate "just use SQL" have a bizarre aversion to applying the same learning effort to their ORM. > I've had weekends ruined troubleshooting my "highly productive ORM layer" that nuked a production database. Whilst functionally speaking my OR…

[deleted]

Re: Things I learned after getting users

#53
post #49
post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

> learn SQL properly. It's not that hard. Focus on it for a few weeks intensely and you've mastered it for life. Exactly the same is true of ORMs. I find most of the people who advocate "just use SQL" have a bizarre aversion to applying the same learning effort to their ORM. > I've had weekends ruined troubleshooting my "highly productive ORM layer" that nuked a production database. Whilst functionally speaking my OR…

> bizarre aversion to applying the same learning effort to their ORM

Oh, sure, instead of just learning SQL I'll just learn SQL, the ORM, the ORM's weird edge case features that actually support the SQL I want, the undocumented ORM internals that prevent the good query from actually being generated, and then I'll commit a patch to the open source project to fix the undocumented internals and shepherd a custom dependency for 6 months while it gets into a numbered release. Then I'll do it all over again when I switch stacks and have to learn a completely new ORM.

Or I could just use SQL.

Re: Things I learned after getting users

#54
post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

What do you think of "micro ORMs" like knex.js, or Dapper for C#? I personally agree with you and my personal projects just use stored procedures, but these micro orms have always piqued my interest since they're just a SQL abstraction for building single queries.

I would consider those "query builders" rather than fully fledged ORMs.

Re: Things I learned after getting users

#55
post #49
post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

> learn SQL properly. It's not that hard. Focus on it for a few weeks intensely and you've mastered it for life. Exactly the same is true of ORMs. I find most of the people who advocate "just use SQL" have a bizarre aversion to applying the same learning effort to their ORM. > I've had weekends ruined troubleshooting my "highly productive ORM layer" that nuked a production database. Whilst functionally speaking my OR…

Yes, both SQL and ORMs can give you problems, but I have seen far more serious, hard to diagnose trouble from ORMs than straight SQL.

Learning straight SQL is far more transferable across databases than learning an ORM.

There are reasons to have ORMs, for e.g. to keep a large code base consistent. It's useful for keeping relatively simple queries consistent across an ERP system, stuff like that.

However, learning SQL is going to have a far higher payoff across your career.

Re: Things I learned after getting users

#56
post #50

Earlier quoted context omitted.

If writing SQL directly, what process do you use to update your queries during schema changes? Do you rely on a test suite to catch errors then update queries by hand? Are you using compile-time checks through libraries like sqlx [1]? [1]: https://github.com/launchbadge/sqlx

Sorry to butt heads there, but what ORM does automatically handle schema changes? I have so many teams with highly abstracted ORMs telling me that no-downtime schema changes are impossible, no matter how trivial the changes are, or would be in e.g. Hibernate. And the only team capable of zero-downtime schema changes uses a minimal DSL to SQL lib.

This problem seems foreign to me. Are your teaming not using Laravel? If not maybe it's time to upgrade. https://laravel.com/docs/10.x/eloquent

Re: Things I learned after getting users

#57
post #50

Earlier quoted context omitted.

If writing SQL directly, what process do you use to update your queries during schema changes? Do you rely on a test suite to catch errors then update queries by hand? Are you using compile-time checks through libraries like sqlx [1]? [1]: https://github.com/launchbadge/sqlx

Sorry to butt heads there, but what ORM does automatically handle schema changes? I have so many teams with highly abstracted ORMs telling me that no-downtime schema changes are impossible, no matter how trivial the changes are, or would be in e.g. Hibernate. And the only team capable of zero-downtime schema changes uses a minimal DSL to SQL lib.

I don't know of any ORM that handles schema changes automatically (edit: for the most strict definition of "automatically" -- I've used ORMs that generate migration files and am generally happy with them).

My experience here is quite limited, so I'm inclined to defer to yours. With that caveat, I find that ORMs play more nicely with my IDE (e.g. I can rename a column name and automatically update all call sites) and often raise early warnings if their declarative classes are out of sync with the underlying table schema.

Re: Things I learned after getting users

#58
post #4

> when the site first got a surge of users from hacker news, there was one poster in particular who came to the site, registered a bunch of offensive, racist usernames and proceeded to post and create threads that were just full of dumb slurs. this was definitely a learning experience because i had to act quickly, so i tried a bunch of different methods to get rid of him. it's sad that people like this exist in the w…

> I said that's life

> (That's life)

> And as funny as it may seem

> Some people get their kicks

> Stomping on a dream

> But I don't let it, let it get me down

> Cause this fine old world, it keeps spinnin' around

- That’s Life

By Dean Kay and Kelly Gordon. Most famously recorded by Frank Sinatra.

Re: Things I learned after getting users

#59
post #4

> when the site first got a surge of users from hacker news, there was one poster in particular who came to the site, registered a bunch of offensive, racist usernames and proceeded to post and create threads that were just full of dumb slurs. this was definitely a learning experience because i had to act quickly, so i tried a bunch of different methods to get rid of him. it's sad that people like this exist in the w…

I spent some time working in a prison, it was very eye opening for someone like me from a pretty sheltered background. Most of the inmates were decent enough people that made bad choices but there were a few who were just horrible sadistic bullies.

Re: Things I learned after getting users

#60
post #49

Earlier quoted context omitted.

> learn SQL properly. It's not that hard. Focus on it for a few weeks intensely and you've mastered it for life. Exactly the same is true of ORMs. I find most of the people who advocate "just use SQL" have a bizarre aversion to applying the same learning effort to their ORM. > I've had weekends ruined troubleshooting my "highly productive ORM layer" that nuked a production database. Whilst functionally speaking my OR…

> bizarre aversion to applying the same learning effort to their ORM Oh, sure, instead of just learning SQL I'll just learn SQL, the ORM, the ORM's weird edge case features that actually support the SQL I want, the undocumented ORM internals that prevent the good query from actually being generated, and then I'll commit a patch to the open source project to fix the undocumented internals and shepherd a custom depende…

How do I map my complex join into a list of structs with embedded associations? I'd probably need to write a good bit of code just to unmarshal the data, right? How are you doing this every time you write a new query?
Post reply on HN