The ORM is really not good in my opinion because it is ActiveRecord'ish and has all its downsides. I wouldn't use Django for any moderately complex domain. But even with simpler CRUD style apps I don't really see the point in it.
The ORM is really not good in my opinion because it is ActiveRecord'ish and has all its downsides. I wouldn't use Django for any moderately complex domain. But even with simpler CRUD style apps I don't really see the point in it.
The one thing I really appreciate with the ORM is that you really can get the ORM to make... more or less any sort of SQL query you want.
It can take a while to wrap your head around what fields get used in aggregates and the like, but when working with big models with like 65 fields and juggling a bunch of stuff, not having to futz with serialization/deserialization and "just" expressing your problem in the dumb way is nice.
I want to say this all comes back to bite you in the end but honestly it's more just having wide tables that comes to bite you. A service layer wouldn't really save you. Meanwhile you save yourself a bunch of tedium in the mean time
> The one thing I really appreciate with the ORM is that you really can get the ORM to make... more or less any sort of SQL query you want.
And if you can't make the ORM make the SQL query you want, you can just write it as a SQL query, like this godawful monstrosity:
... which calculates the Haversine distance from where you are now to the five nearest points.I am in roughly equal parts proud of and horrified by this creation.
Site.objects.annotate( distance=Degrees(ACos(Cos(.....))), latpoint=float(lat), lngpoint=float(lon), ).order_by("distance")[:5]
for function calls, look at django.db.models.functions, you can find a bunch of stuff in there or create custom ones super easily (like "two lines of codes" easily)
I mean you have a thing that works in theory so it's a bit of navel gazing, though.
I'm not seeing anything that can't be done here without using raw() though?
Yeah I'm not clever enough to do that.
How would you have approached it?
What would you have done Instagram from instead of Django?
Elixir and Phoenix.
You'd have written Instagram which was released in 2010 in Elixir which wasn't released to the public til 2012?
So Rails or some PHP framework. It was slightly too early to go full Node. Django was a little unusual too among the developers I knew. Java was still a thing but more for finance related projects.
Well 2010 PHP and the frameworks at the time were still going through the 5.x desert journey, and the prospects weren't entirely clear with the cancellation of PHP 6, so you wouldn't fault your 2010 self for not trying to push some Drupal/Joomla/Magento to that scale.
Kinda took until Facebook showing off Hacklang in 2014 for people to believe in getting more canonical programming features into PHP and make it more performant. So it would have been a good decision if one could predict 10 years into the future, but nobody can.
Rails was fully into growing pains and maintainability crises (some large rails codebases took years to migrate) and PHP was in transition; some good things by then but it was not what it is now.
All of the gripes OP has with Django are arguably worse in Rails.
I think Threads could have been done in Elixir.
Why would you have chosen these? What are the advantages?
I mean if you're doing it this way, you're really not applying best practices as a developer (never mind as a Django developer).
> Models being passed around everywhere, queries happening everywhere.
No, as a developer you still need to be 100% aware of the underlying queries and potential performance issues. No excuse for N+1 problems. ORM is not an excuse to be lazy, but I admit it will probably catch quite a few developers.
Those same developers would probably make a mess out of any other framework or technology though.
Django allowing queries to be anywhere is more or less in line with Python’s overarching “we’re all consenting adults here” ethos. There’s probably one correct way to do it, but if you want to shoot yourself in the foot then here’s your gun.
It definitely takes a bit of discipline. The key layers are somewhat easy to manage—middleware, context processors, views, template tags—but I’ve seen some hairy lasagne further obscuring where the queries happen on top of that. A well-documented abstraction can be useful, but if it is possible to keep it simple and obvious then that’s the way to go.
(Third-party dependencies can further complicate things, but at least you can expect a library using ORM to be in the installed apps list.)
I'm semi-assuming we're talking about professionals who'd excel with their products in any framework and language.
It's highly productive if you do it right.