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

Some notes on starting to use Django

jvns.ca

Post reply on HN
Print view View original

101–110 of 145 posts

Re: Some notes on starting to use Django

#101

Post by limagnolia »

igsomething wrote: post #23
hansonkd wrote: post #11

Earlier quoted context omitted.

Its crazy to me after all these years that django-like migrations aren't in every language. On the one hand they seem so straightforward and powerful, but there must be some underlying complexities of having it autogenerate migrations. Its always a surprise when i went to Elixir or Rust and the migration story was more complicated and manual compared to just changing a model, generating a migration and committing. In…

Going from Django to Phoenix I prefer manual migrations. Despite being a bit tedious and repetitive, by doing a "double pass" on the schema I often catch bugs, typos, missing indexes, etc. that I would have missed with Django. You waste a bit of time on the simple schemas, but you save a ton of time when you are defining more complex ones. I lost count on how many bugs were introduced because someone was careless wit…

Django doesn't force anyone to use the automatic migrations, you can always write them manually if you want to :)

Re: Some notes on starting to use Django

#102

Post by selcuka »

stuaxo wrote: post #78

Nice. As a mostly-django-dev for the last 15 years, who's been exposed to FastAPI and various ORMs again recently, I should get round to write a doc about some Django bits. Django is pretty nice, the changes between versions are small and can be managed by a human. Part of the reason that you can have the big ecosystem is that there is a central place to register settings and INSTALLED_APPS, middleware etc. That enab…

> Coming to a FastAPI app with alembic and finding a lot of that is build-it-yourself (and easily break it) is a bit of a shock.

I briefly played with FastAPI, and after the same shock I discovered Django-Ninja [1]. It's modeled after FastAPI and async-capable (if you are inclined, but warning, there be dragons). It plays nicely with all parts of Django, including the ORM.

[1] https://django-ninja.dev/

Re: Some notes on starting to use Django

#103

Post by globular-toast »

tmarice wrote: post #48

After working with Django for 8 years, I find it hard to move on to anything else. It's just the right amount of magic, and just the right amount of flexibility, and it's just such a joy to work with. Re: Django is OK for simple CRUD, but falls apart on anything complex - this is just untrue. I have worked in a company with a $500M valuation that is backed by a Django monolith. Reporting, recommender systems, file in…

How do the apps "interconnect"? In my experience, unless you're careful, a Django monolith quickly becomes a big ball of mud. I've recently started to use Tach to try to combat this.

Re: Some notes on starting to use Django

#104

Post by Izkata »

stuaxo wrote: post #78

Nice. As a mostly-django-dev for the last 15 years, who's been exposed to FastAPI and various ORMs again recently, I should get round to write a doc about some Django bits. Django is pretty nice, the changes between versions are small and can be managed by a human. Part of the reason that you can have the big ecosystem is that there is a central place to register settings and INSTALLED_APPS, middleware etc. That enab…

> as a solution for a problem Django solved years ago with it's test database support.

I believe it's now accurate to even say "decades ago".

Re: Some notes on starting to use Django

#105

Post by agumonkey »

simonw wrote: post #17
interroboink wrote: post #6

Django aside, I think this is a really important point: Being able to abandon a project for months or years and then come back to it is really important to me (that’s how all my projects work!) ... It's perhaps especially true for a hobbyist situation, but even in a bigger environment, there is a cost to keeping people on hand who understand how XYZ works, getting new people up to speed, etc. I, too, have found found…

This is the main reason I'm extremely disciplined about making sure all of my personal projects have automated tests (configure to run in CI) and decent documentation. It makes it so much easier to pick them up again in the future when enough time has passed that I've forgotten almost everything about them.

Do you preemptively force yourself to allocate time for documentation maintenance ?

Re: Some notes on starting to use Django

#106

Post by bb88 »

otherme123 wrote: post #61
sgt wrote: post #51

Earlier quoted context omitted.

You can absolutely scale Django. The framework itself is not the limiting factor. The main constraint of performance usually comes from Python itself (really slow). And possibly I/O. There are well established ways to work around that. In practice, lots of heavy lifting happens in the DB, can you can offload workloads to separate processes as well (whether those are Python, Go, Rust, Java etc). You need to identify t…

> And the obvious for any Django dev; select_related, prefetch_related, annotate And sometimes not so obvious, I have been bitten by forgetting one select_related while inadvertedly joining 5 tables but using only 4 select_related: the tests work OK, but the real data has a number of records that cause a N+1. A request that used to take 100ms now issues "30 seconds timeout" from time to time. Once we added the missin…

You may already know this, this is meant for others hitting this issue frankly.

In Django, you can count the number of queries in a unit test. You don't need 1M objects in the unit test, but maybe 30 in your case.

If the unit code uses more than X queries, then you should assume you have an N+1 bug. Like if you have 3 prefetch related and 2 select related's on 30 objects, but you end up with more than 30 queries, then you have an N+1 someplace.

Even better that unit test will protect you from hitting that error in the future in that chunk of code accessing that table.

Re: Some notes on starting to use Django

#107

Post by simonw »

agumonkey wrote: post #105
simonw wrote: post #17

Earlier quoted context omitted.

This is the main reason I'm extremely disciplined about making sure all of my personal projects have automated tests (configure to run in CI) and decent documentation. It makes it so much easier to pick them up again in the future when enough time has passed that I've forgotten almost everything about them.

Do you preemptively force yourself to allocate time for documentation maintenance ?

Not really.

I have a rule that any commit which changes the implementation has to include the documentation update at the same time.

Most of these documentation updates are a sentence or two, or maybe a paragraph. The overhead of incremental documentation updates like that is tiny enough that I don't really think about assigning extra time for them.

Re: Some notes on starting to use Django

#108

Post by Nextgrid »

dnautics wrote: post #91
gtaylor wrote: post #24

Earlier quoted context omitted.

The nice thing in this case is that Django will meet you where you are with your preferences. Want to go the manual route? Sure. Want it to take a shot at auto-generation and then you customize? Very doable and. Want to let Django take the wheel fully the majority of the time? Sure.

is this like the "it takes 50 hours to set up a project management tool to work the way you want "? what happens if you onboard a superstar that works with django some other way?

> what happens if you onboard a superstar that works with django some other way

If you hired a "superstar" that goes out of their way to hand-write migrations in cases where Django can do it by default (the majority of them) you did not in fact get a superstar.

I have yet to see anyone hand-roll migrations on purpose. In fact the problem is usually the opposite, the built-in migration generator works so well that a lot of people have very little expertise is doing manual migrations because they maybe had to do it like 5 times in their entire career.

Re: Some notes on starting to use Django

#109

Post by ltbarcly3 »

IMO Django is a buggy and poorly designed framework that locks you into bad decisions.

It's a combination of things that all suck: the - ORM (sqlalchemy is better in every possible way. django's orm is very poor and can't express a lot of sql constructs at all) - templates (jinja2 is basically identical except performant and debuggable) - routing (lots of wsgi routers exist and are lightyears ahead of django)

Don't use Django.

Reference (me saying the same thing 16 years ago): https://news.ycombinator.com/item?id=1490415

Re: Some notes on starting to use Django

#110

Post by Izkata »

wiredfool wrote: post #56
cuu508 wrote: post #53

Earlier quoted context omitted.

Can you give an example how this would happen?

Ok, from memory -- There's a pre, do and post phase for the migrations. When you run a single migration, it's: pre, do, post. When you run 2 migrations, it's: pre [1,2], do: [1,2], post: [1,2]. So, if you have a migration that depends on a previous migration's post phase, then it will fail if it is run in a batch with the previous migration. When I've run into this is with data migrations, or if you're adding/assigin…

This doesn't sound at all familiar, are you sure you're not mixing it up with something else?
Post reply on HN