Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What ORMs have taught me: just learn SQL (2014)

wozniak.ca

Post reply on HN
Print view View original

271–280 of 305 posts

Re: What ORMs have taught me: just learn SQL (2014)

#271

Post by teacup50 »

int_19h wrote: post #225
teacup50 wrote: post #184

Earlier quoted context omitted.

Data encapsulation (e.g. via ADTs) does not equal "OO".

I would argue that OO is polymorphism + innate object identity. Though the latter only matters if you have mutability; but then, whether OO without mutability is "true OO" is one of those deeply philosophical questions.

I find the dividing line in formalism; we can always find similarities with language-level features from OO, but OO is by definition an informal set of ideas about how programming is best done and understood, rooted deeply in empiricism, not formal theory and analysis.

If I can model your type/language model as a higher-kinded dependently typed lambda calculus (e.g. using Boehm-Berarducci encoding for non-turing complete recursive ADT definitions), then it's not OO -- it's functional programming, rediscovered.

Re: What ORMs have taught me: just learn SQL (2014)

#272

Post by thomasahle »

JustSomeNobody wrote: post #255
eudox wrote: post #86

Earlier quoted context omitted.

Parameterized queries are to prevent injection. They don't tell you, at compile time, when you're building an invalid/unrepresentable SQL query.

No, but your unit tests should catch bad queries and then you're good to go.

You can use that argument against any kind of static analysis/checking.

Re: What ORMs have taught me: just learn SQL (2014)

#273

Post by rsyntax »

coldtea wrote: post #270
rkuykendall-com wrote: post #267

Earlier quoted context omitted.

Because toast0 knows what they wrote, but a team member wouldn't. So instead of googling "Flask add cookie to response" you have to start digging through all of toast0's code to see if they even have a way. At least that's why I would consider working on a team like that much worse.

> Because toast0 knows what they wrote, but a team member wouldn't. They wouldn't know vanilla SQL, HTML, WSGL, etc, --decade old standards-- etc, but they would know some random framework like Flask?

"Custom" framework.. idiosyncratic code. Code that is probably not properly documented, not properly vetted, or maintained as technology evolves. It is not to say it can't be done (e.g. fb, google, ms), but the cost of doing so greatly outweighs the benefits. For example, security concerns of your "custom" framework and onboarding of new engineering into your team. And are you really in the business fo "custom" framework?

Re: What ORMs have taught me: just learn SQL (2014)

#274

Post by maxxxxx »

ZanyProgrammer wrote: post #269
intrasight wrote: post #146

Earlier quoted context omitted.

Please elaborate

1.They are a pain in the ass to keep track of in version control. 2. They are hard to debug, especially when lots of business logic gets dumped to them

Totally agree. It's hard to do code and stored procedures right with the same level of quality. The tools are different and the thinking is different.

Re: What ORMs have taught me: just learn SQL (2014)

#275

Post by EGreg »

z92 wrote: post #195
EGreg wrote: post #182

Earlier quoted context omitted.

ORMs let you structure your queries in a way that allows the app to understand them and analyze them, for sharding purposes. True, you can write SQL and then parse it yourself in a proxy, but why?

If your ORM allows you to drop down to SQL, which the parent claims all modern ORMs do, then you will still need that SQL parser in your ORM.

You can have a small subset of your queries in raw SQL and if you really need to shard them, you mark them up with structured metadata. But the rest would be automatically structured, analyzed and sharded.

Re: What ORMs have taught me: just learn SQL (2014)

#276

Post by fbonetti »

jeltz wrote: post #233
fbonetti wrote: post #30

Earlier quoted context omitted.

That's really easy. Post.select("posts.*, count(comments.*) as comments_count").joins(:comments)

That is not the same query at all. You need to do a left join and a group by for it to become the same query. Wihout a left join posts without comments wont show up in the result.

You're totally right. My example is an inner join. I will admit that doing outer joins in ActiveRecord is quite painful. Here's a more realistic example, which is not nearly as pretty:

  Post.select("posts.*, COUNT(comments.*) AS comments_count").joins("LEFT JOIN comments ON comments.post_id = posts.id").group(:comments)

Re: What ORMs have taught me: just learn SQL (2014)

#278

Post by _pmf_ »

lukaseder wrote: post #244
_pmf_ wrote: post #238

Earlier quoted context omitted.

I was intrigued by jOOQ, but the huge amount of generated code for internal metadata of the DB was a bit offputting. I don't want 4MB of generated classes for 3 very small tables.

Use the code generator's or flag or other means and you'll only get those 3 small tables generated...

Ah, thank you, this does the trick; I first tried to use my database name as inputSchema, but I had to use "public" in PG.

Re: What ORMs have taught me: just learn SQL (2014)

#279

Post by taurath »

rsyntax wrote: post #273
coldtea wrote: post #270

Earlier quoted context omitted.

> Because toast0 knows what they wrote, but a team member wouldn't. They wouldn't know vanilla SQL, HTML, WSGL, etc, --decade old standards-- etc, but they would know some random framework like Flask?

"Custom" framework.. idiosyncratic code. Code that is probably not properly documented, not properly vetted, or maintained as technology evolves. It is not to say it can't be done (e.g. fb, google, ms), but the cost of doing so greatly outweighs the benefits. For example, security concerns of your "custom" framework and onboarding of new engineering into your team. And are you really in the business fo "custom" frame…

A purpose built application if built well will not only do the job more efficiently but also be easy to maintain. If you write exclusively attached to a framework it creates just as much work for someone who knows the underlying technologies but not the framework as it would for someone who knows a framework. You'll end up tying your application to that framework. Sure, say you want to quickly hire 20 coders to work on a project - use a framework (or be like Facebook, or Google and create your own...). I've found hiring framework developers is a good path to getting work only in that framework. Devs who are more versed in the underlying technologies have in my experience been more flexible and put out better products for the domain they're working in.

Re: What ORMs have taught me: just learn SQL (2014)

#280

Post by lukaseder »

_pmf_ wrote: post #278
lukaseder wrote: post #244

Earlier quoted context omitted.

Use the code generator's or flag or other means and you'll only get those 3 small tables generated...

Ah, thank you, this does the trick; I first tried to use my database name as inputSchema, but I had to use "public" in PG.

I see, yes. The database corresponds to jOOQ's Catalog, not the Schema (except in MySQL, which mixes up these concepts)
Post reply on HN