undefined | Better HN

0 pointsmatsemann3y ago0 comments

> If `course.has_finished` is a property of the course, why would you want to have a separate function outside of the class?

Because one should avoid passing Django models around. It leads to bad design. Have a selector or something that uses the ORM, but exposes some dataclass or pydantic model instead, and put the logic there.

0 comments

Nextgrid3y ago

Keep in mind that passing around querysets has performance advantages you wouldn't get by passing around dataclasses or similar.

For example, if you do a query like Model.objects.filter(related_model__in=RelatedModel.objects.filter(...)) the ORM will only run a single query, silently converting the second one into a JOIN.

If you pass lists of "RelatedModel" however you would've had to first one one query to get that list (raising potential edge-cases with regards to atomicity and transactional isolation) and then pass the list of IDs to the outer query in an "WHERE related_model_id IN (...)", resulting in 2 queries in the end.

matsemannOP3y ago

That gain is often lost by people doing unoptimized queries all over the place, though, instead of a single place where the queries are optimized. And passing the fat django objects around often lead to accidental n+1 queries, since you can't really trust that looking up a property on your object doesn't do a new query. Often nicer to avoid it all, by having a gated access to the DB.

While I propose most often sending in a list of related IDs (premature optimization and all that), the function could just accept any iterable, and you from the outside could send in the lazy relatedmodel query.

traverseda3y ago

You want to add an ORM to the ORM? Why?

matsemannOP3y ago

How is that adding an ORM to the ORM? I want all django orm access to happen at defined places, instead of the spaghetti mess it is when people do SomeOtherModulesModel.objects.filter(..) and expose themselves to the internal workings of that module. Access it through a selector instead.

rglullis3y ago

If for some strange reason your application has data that it was not created with Django, sure.

But aside from that you are just adding another layer of abstraction that does not give any benefit when all your models are managed by Django already.

1 more reply

traverseda3y ago

An orm takes a selector (typically an sql query) and maps it onto an object.

What you're describing takes a selector, and maps it onto an object. Is it just that you want type hints or something?

1 more reply

j / k navigate · click thread line to collapse

0 comments

Nextgrid3y ago

Keep in mind that passing around querysets has performance advantages you wouldn't get by passing around dataclasses or similar.

For example, if you do a query like Model.objects.filter(related_model__in=RelatedModel.objects.filter(...)) the ORM will only run a single query, silently converting the second one into a JOIN.

matsemannOP3y ago

traverseda3y ago

You want to add an ORM to the ORM? Why?

matsemannOP3y ago

rglullis3y ago

If for some strange reason your application has data that it was not created with Django, sure.

But aside from that you are just adding another layer of abstraction that does not give any benefit when all your models are managed by Django already.

1 more reply

traverseda3y ago

An orm takes a selector (typically an sql query) and maps it onto an object.

What you're describing takes a selector, and maps it onto an object. Is it just that you want type hints or something?

1 more reply

j / k navigate · click thread line to collapse