undefined | Better HN

0 pointsOJFord4y ago0 comments

What do you do when what you want/need is not representable in the ORM?

For example: https://stackoverflow.com/questions/65596920/use-django-subq...

Composite types & triggers, for some other examples, are only (at least they are!) available via third-party plugin/'installed app's too. You cannot defer a Django unique 'constraint', because it happens to implement it as a unique index instead.

That's just the few that come to mind.

0 comments

8 comments · 2 top-level

notJim4y ago· 3 in thread

For the SO question, why do you need to represent that in the ORM? It seems like you've got the SQL, and most ORMs have an escape hatch to just run SQL. Does Django not?

OJFordOP4y ago

I responded to the same point in a comment there at the time iirc. No reason other than to be friendly/idiomatic to a project and colleagues that's largely Django.

We've used more and more SQL though, for things Django doesn't support, such as (materialised) views. (You can use models with managed=False, but not have it manage their DDL & schema migrations.)

I still try to use Django where possible and especially if it's auxiliary to a Django-managed table though.

gabereiser4y ago

Bingo. This. If you’ve broken your relational model then go ahead and use raw sql with your orm. They all support a way of executing raw sql against your data. This is the exception, not the norm.

OJFordOP4y ago

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.

2 more replies

gabereiser4y ago· 3 in thread

The problem is not the orm, it’s how you are treating data. The ORM has features for doing “out of the box” sql if you happen to fuck up your relational model. Which you clearly have in your s/o post. It’s ok, we all make mistakes. SQL modeling has been screwed up many many many times. For these rare occasions where the orm doesn’t match the object model or the desired action you are trying to achieve, there are ways to use raw sql, when necessary. Your case, it’s necessary as the relational model is broken.

OJFordOP4y ago

So, is anything that is representable in SQL but not in Django's tiny subset a 'fuck up'?

Like many 9s of development are, it's brownfield anyway, so you're saying the ORM should only be used if one's prepared to make large schema changes?

DangitBobby4y ago

Django's default subset is enough to do 99.9% of what you'd need to do (I know from experience) and there are various packages you can install to extend the ORM if necessary or if it just makes your life easier.

Of course, as the other person said, you can always always always descend into raw SQL if you must or if it just saves you time.

gabereiser4y ago

That’s not what I said at all.

1 more reply

j / k navigate · click thread line to collapse

0 comments

8 comments · 2 top-level

notJim4y ago· 3 in thread

For the SO question, why do you need to represent that in the ORM? It seems like you've got the SQL, and most ORMs have an escape hatch to just run SQL. Does Django not?

OJFordOP4y ago

I responded to the same point in a comment there at the time iirc. No reason other than to be friendly/idiomatic to a project and colleagues that's largely Django.

We've used more and more SQL though, for things Django doesn't support, such as (materialised) views. (You can use models with managed=False, but not have it manage their DDL & schema migrations.)

I still try to use Django where possible and especially if it's auxiliary to a Django-managed table though.

gabereiser4y ago

Bingo. This. If you’ve broken your relational model then go ahead and use raw sql with your orm. They all support a way of executing raw sql against your data. This is the exception, not the norm.

OJFordOP4y ago

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

2 more replies

gabereiser4y ago· 3 in thread

OJFordOP4y ago

So, is anything that is representable in SQL but not in Django's tiny subset a 'fuck up'?

Like many 9s of development are, it's brownfield anyway, so you're saying the ORM should only be used if one's prepared to make large schema changes?

DangitBobby4y ago

Of course, as the other person said, you can always always always descend into raw SQL if you must or if it just saves you time.

gabereiser4y ago

That’s not what I said at all.

1 more reply

j / k navigate · click thread line to collapse