undefined | Better HN

0 pointsOJFord4y ago0 comments

I just don't see the value in using one for the trivial stuff (select from join where); the intermediate stuff is longer, more verbose, more DSLy (functions, aggregates, groups); and anything rarer/more 'advanced' is just missing.

The useful bit is de/serialisation from 'model' <-> query/record, IMO. Everything else is just limitation.

0 comments

4 comments · 2 top-level

notJim4y ago· 2 in thread

I think I feel the opposite to you. I want the ORM to handle the trivial stuff like SELECT * FROM table WHERE id=? and UPDATE table SET thing=? WHERE id=?. That's the lion's share of what I'm doing in an app, and it's pointless to type it out with slight variations repeatedly.

On the other hand, for complex stuff, I'd rather write the raw SQL, since it's in a real language and not some half-baked, under-documented DSL that everyone onboarding onto the project will be unfamiliar with.

OJFordOP4y ago

> I want the ORM to handle the trivial stuff like SELECT * FROM table WHERE id=? and UPDATE table SET thing=? WHERE id=?.

Why are list(Table.objects.filter(id=?)) and Table.objects.filter(id=?).update(thing=?) better?

That's what I mean by the trivial, it's 'handled', sure, with some pointless (IMO) thin wrapper that's Django-specific to learn. (Sure it's not loads to learn, but it has its quirks. I always have to check the meaning of the 'defaults' kwarg to update it create for example.)

> On the other hand, for complex stuff, I'd rather write the raw SQL, since it's in a real language and not some half-baked, under-documented DSL that everyone onboarding onto the project will be unfamiliar with.

Yes, I agree! I just think the trivial wrapper stuff isn't valuable, and especially if I'm using raw SQL for less trivial stuff, I may as well always do so.

I think my comment above might've sounded ambiguously like maybe I wanted DSL for more complex stuff. That's not what I meant - I meant that it tends to be more complex in the DSL than in SQL, up to the point where it's just impossible in the DSL, and you either use SQL or don't do it.

notJim4y ago

> Why are list(Table.objects.filter(id=?)) and Table.objects.filter(id=?).update(thing=?) better?

I'm not familiar with SQLAlchemy, but with other ORMs, this isn't how you'd write this.

It would be more like Widgets.findOne(id) and then widget.property = bla; widget.save();

For me this is much more natural than writing SQL, especially for the update query.

There are usually also query helpers for simple queries by fields, like Table.findWhere({property: 'value', property2: 'value2'}).

To me this syntax is much less awkward than writing SQL in strings, and it saves you from repeatedly writing out the SELECT statements and where clauses.

1 more reply

gabereiser4y ago

If you are putting business logic in your database, you are doing it wrong. I get your point. Which is why I said it’s sometimes ok to run with raw sql with your orm. The problem is your database is really great at storing and retrieving data. Keep it doing what it’s good at and do your aggregate work on a separate machine where you have cpu cycles to spare. This is the point. I’ve told people before about hibernate and it’s foreign key constraints on models - “sometimes is best to not define the relationship at the model and just make another trip to the database to load”. Heavily utilized databases are a bottleneck to your systems, stop making them do the work. Do it on the edge.

j / k navigate · click thread line to collapse