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

Django 5.0

djangoproject.com

Post reply on HN
Print view View original

101–110 of 237 posts

Re: Django 5.0

#101

Post by fbdab103 »

BasilPH wrote: post #30
danpalmer wrote: post #16

Earlier quoted context omitted.

I've always felt, and this hasn't changed recently, that if you're going to need more than, say, 3 of the cross cutting concerns that Django provides for, then it'll be much more maintainable in the long run to just use Django rather than effectively building a custom solution out of parts. The flip side: if you're building a small internal API that only needs a couple of these, Django might be overkill. What do I me…

I agree. I would even go so far as to say that if you need an ORM, go with Django. I've wasted too much time adding SQLAlchemy to Flask to get something that is still worse than the Django ORM.

+1 to that. Maybe SQLAlchemy is a better product, but being a bolted on solution makes everything about the ORM experience feel worse than using Django. If nothing else, it is not just using Flask+SQLAlchemy, now it is Flask+SQLAlchemy+Alembic. Or maybe, you want the niceties, so it is Flask+SQLAlchemy+Alembic+FlaskMigrate.

Re: Django 5.0

#102

Post by rollcat »

ralmidani wrote: post #35

Django made me fall in love with programming 13 years ago, and since then it has always had a special place in my heart. I’m revisiting a business idea I was working on for a couple years, before I sought and found employment in the industry (where I used Java for a couple years, then Elixir for a couple more). My project was built with Django and Django REST Framework, and Ember on the client-side. 6 years later, th…

> 6 years later, the Django side needed minimal changes and is up and running (I jumped all the way from 1.11 to 5.0 beta).

I've been using Django since before 1.0, and the upgrade story has been nothing short of fantastic for something that's been around this long. But still, YMMV!

Depending on how ancient a project you run into, it definitely can be a major pain, even with the original authors' best intentions. For example, Django didn't have its own DB migration system until 1.7 (relying on third party solutions); this means you also have to adjust the deployment procedure, which means recreating an ancient setup (ideally in an easily repeatable fashion, because you're going to be trying that migration at least a dozen times).

The builtin admin system is also a pretty decent CMS on its own, but falls short as you run into slightly more complex use cases (such as basically anything that requires even a single line of JS). The docs will encourage you to copy and override the builtin templates; this often becomes a pain point during upgrades. It's wise to get off the builtin admin system as your project grows.

Re: Django 5.0

#103

Post by Alex3917 »

rollcat wrote: post #102
ralmidani wrote: post #35

Django made me fall in love with programming 13 years ago, and since then it has always had a special place in my heart. I’m revisiting a business idea I was working on for a couple years, before I sought and found employment in the industry (where I used Java for a couple years, then Elixir for a couple more). My project was built with Django and Django REST Framework, and Ember on the client-side. 6 years later, th…

> 6 years later, the Django side needed minimal changes and is up and running (I jumped all the way from 1.11 to 5.0 beta). I've been using Django since before 1.0, and the upgrade story has been nothing short of fantastic for something that's been around this long. But still, YMMV! Depending on how ancient a project you run into, it definitely can be a major pain, even with the original authors' best intentions. For…

FWIW I've also had the same experience; the last version of Django where upgrading took a non-trivial amount of time was 1.8, because it changed how isolation is enforced within test cases. Since then it's rarely taken more than an hour or two, regardless of how big the codebase is.

Re: Django 5.0

#105

Post by quantiq »

Django is such a lovely framework I can't speak higher praises of it. I'm blessed to still be able to use it in my day to day work. It's maybe not the most flashy framework out there these days but Django and Rails are really the Toyota Corollas and Honda Civics of the web dev world that often go so underappreciated for their unfussy reliability. :)

Re: Django 5.0

#106

Post by robertlagrant »

ralmidani wrote: post #45
freedomben wrote: post #5

Earlier quoted context omitted.

Have you worked with ActiveRecord or Ecto? Just wondering for framing your comment

Not who you’re asking, but I’ve used all 3. I think in terms of query interface you can’t go wrong with any of them. In fact, I like Ecto the most because of its separation between the concept of a “Query” (super flexible and composable) vs. a “Repo” (the module where you call an actual database operation). This helps you avoid hitting the database until you’re sure you want to. Where Django’s ORM shines is in the mo…

I think SQLAlchemy is better, personally. Still just model files, but it's data mapper pattern means you won't be hitting all the issues people do with active record.

Re: Django 5.0

#107

Post by mattgreenrocks »

winrid wrote: post #77
ralmidani wrote: post #35

Django made me fall in love with programming 13 years ago, and since then it has always had a special place in my heart. I’m revisiting a business idea I was working on for a couple years, before I sought and found employment in the industry (where I used Java for a couple years, then Elixir for a couple more). My project was built with Django and Django REST Framework, and Ember on the client-side. 6 years later, th…

Django and django-unicorn is really nice. It feels like meteorjs but for Django, extremely productive. I've been working with the creator closely and he's awesome.

django-unicorn is really impressive! So glad to see people pushing back on all the gunk inherent in webdev still.

Re: Django 5.0

#108

Post by the__alchemist »

Django owns! The blazingly-fast flask-alikes that come out in Python and Rust every year still can't touch it for building websites.

My only beef is that the official docs and community chats make you feel like you're an outlaw or doing things wrong if you use the raw SQL API.

Regarding this new version in particular, the feature that jumps out at me the most is the improved field choices. I've been using an odd workaround with the decorator API to tie them to python Enums.

Re: Django 5.0

#109

Post by nrjames »

miiiiiike wrote: post #88
nrjames wrote: post #85

Earlier quoted context omitted.

Not a large site, but I used django-ninja in production for internal tooling at a very large game dev/publishing company. The APIs routinely handle 1000s of calls (via an integration with Dagster) for moving large amounts of data around and into a reporting system. It's rock solid and fast. I'm on v0.22 however and need to do some refactoring to move to 1.0 because of changes to the integration with Pydantic. It is s…

Thanks. 1,000s of calls a second/minute/day?

Because of the integration with Dagster, the calls are made when my Dagster flows run. I also send unreasonably large data payloads. Anything going into Django gets handed to a Celery batch processing job and just returns the job id (Dagster monitors for failure, too). Data pulled out of Django is paginated. Sometimes it's 1000s of calls per minute, sometimes it's none at all for hours. I realize this isn't a normal use case, though. :)

Re: Django 5.0

#110

Post by cdcarter »

radus wrote: post #93
cdcarter wrote: post #82

Earlier quoted context omitted.

GeneratedField looks interesting, but I'm not _really_ sure what gains I get over just calling annotate() on my queryset with some computed fields. At least on the backends where the computed GeneratedField isn't stored.

It's easier to re-use if you need the same generated field in multiple places.

I've been in the habit of replacing the default manager for my model with one with an annotated query set. that way, any Model.objects.all() call will have the computed fields.

I find this pretty easy to get used to and re-use. though I do admit I like them defined as actual model-fields with verbose names etc...

Post reply on HN