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

111–120 of 145 posts

Re: Some notes on starting to use Django

#111

Post by Izkata »

aljarry wrote: post #65
ndr wrote: post #57

Earlier quoted context omitted.

I found it very lacking in how to do CD with no downtime. It requires a particular dance if you ever want to add/delete a field and make sure both new-code and old-code work with both new-schema and old-schema. The workaround I found was to run tests with new-schema+old-code in CI when I have schema changes, and then `makemigrations` before deploying new-code. Are there better patterns beyond "oh you can just be care…

One option is to do multi-stage rollout of your database schema and code, over some time windows. I recall a blog post here (I think) lately from some Big Company (tm) that would run one step from the below plan every week: 1. Create new fields in the DB. 2. Make the code fill in the old fields and the new fields. 3. Make the code read from new fields. 4. Stop the code from filling old fields. 5. Remove the old field…

2.5 (if relevant) mass-migrate data from the old column to the new column, so you don't have to wait forever.

Re: Some notes on starting to use Django

#112

Post by Izkata »

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?

Either way the end result is a single file in migrations/ that describes the change, though you do have to write it with Django's API if you want further migrations to work without issues (so no raw SQL, but this low-level API is things like CreateTable() and AddColumn() - and is what Django generates automatically from the models, so the auto-generated migrations are easily inspectable and won't change).

Re: Some notes on starting to use Django

#113

Post by bigbuppo »

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 also why I write a formal requirements document for all but the smallest throw-away projects. Much easier to know wtf you were thinking 18 months ago if you write down wtf you were thinking at the time.

Re: Some notes on starting to use Django

#115

Post by lmm »

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?

No. Django is very good at having the autogenerated/default stuff be consistent with what you do if you want to write manually, it's not one of those "if you want to use the magic as-is it all just works, if you want to customize even one tiny piece you have to manually replicate all of the magic parts" frameworks.

Re: Some notes on starting to use Django

#116

Post by bhch »

bb88 wrote: post #7

After spending a lot of my time on Django, it's fine for simple to moderately complex things. The ORM mostly good. DRF is fine for APIs. And the admin is super nice as well. But once something gets significantly complex, the ORM starts to fall down, and DRF becomes more of a hindrance. But if you're just doing simple CRUD apps, Django is perfectly serviceable.

> But once something gets significantly complex, starts to fall down.

Vague arguments like this are categorically useless.

Re: Some notes on starting to use Django

#117

Post by fud101 »

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…

>If you ever need a CMS in your Django project I strongly recommend Wagtail, it came after the initially most popular django-cms and learned a lot of lessons - feeling much more like a part of Django.

Nope. I would choose plain Django 100% of the time, especially with LLMs. Wagtail is an antipattern.

Re: Some notes on starting to use Django

#118

Post by selcuka »

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…

Did you mean migration signals (pre_migrate and post_migrate)? They are only meant to run before and after the whole migration operation, regardless of how many steps are executed. They don't trigger for each individual migration operation.

The only catch is they will run multiple times, once for each app, but that can also be prevented by passing a sender (e.g. `pre_migrate.connect(pre_migrate_signal_handler, sender=self)` if you are registering them in your AppConfig.ready method).

Re: Some notes on starting to use Django

#119

Post by mherrmann »

Cool stuff. I just started open sourcing a command-line tool for deploying Django to a server. It handles SSL certs, databases and backups, automatic error emails, and background tasks via celery / redis. The best part? It does not need Docker. It just runs everything on bare metal.

1: https://github.com/mherrmann/djevops

Re: Some notes on starting to use Django

#120

Post by seabrookmx »

Izkata wrote: post #100
senko wrote: post #73

Some more Django recommendations from Frank Wiles of Revsys (Django consultancy): https://frankwiles.com/questions/starting-django-projects/ I'll add a few of my own: * Set up the project using uv * I name the django project "project"; so settings are project/settings.py, main urls are project/urls.py, etc * I always define a custom Django user model even if I don't need anything extra yet; easier to expand later * s…

> * settings.py actually conflates project config (Django apps, middleware, etc) and instance/environment config (Database access, storages, email, auth...); I hardcode the project config (since that doesn't change between environemnts) and use python-dotenv to pull settings from environment / .env; I document all such configurable vars in .env.example, and the defaults are sane for local/dev setup (such as DEBUG=tru…

IMO this is an antipattern because having a python file for each environment means you have bespoke code for each environment that is difficult to test and easily diverges from each other.

If you use OP's way (I do something similar using pydantic-settings) the only thing that changes is your environment vars, which are much easier to reason about.

Post reply on HN