Alternatively look at https://sqlite.org/backup.html for backing up the sqlite db, instead of using VACUUM INTO
Some notes on starting to use Django
31–40 of 145 posts
Re: Some notes on starting to use Django
#32Claude Code is also very good at building basic CRUD apps with Django.
No kidding, it is really good especially with htmx which helps you get some of the advantages of a full SPA without the complexity of a separate frontend. Been building a project in the side to help my studies and it usually implement new complete apps from one prompt, working on the first try
Yeah, I've noticed it regularly suggests htmx (and perhaps something light like alpinejs or some vanilla JS glue logic) to build powerful yet simple interfaces in Django. And it seems to get them right - saving you a lot of time.
Re: Some notes on starting to use Django
#33After 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.
What does significantly complex mean though? You have to make sure you understand the queries made by the ORM, avoid pitfalls like SELECT N+1 queries and so on. If you don't do this, it'll be slow but it's not the ORM's fault - it's that of the programmer.
Re: Some notes on starting to use Django
#34I much prefer Python but am not really seeing any point to doing anything other than JavaScript for web projects at this point. I also do not see much reason to do more than emit JSON on the server side.
> I much prefer Python
Well... that's a valid reason. Why should I work with tool B when I prefer tool A ?
> I also do not see much reason to do more than emit JSON on the server side.
That's the "SPA over API" mindset we need to reconsider. A lot (and I mean A LOT) of projects are way easier to produce and maintain with server-side rendered views.
Re: Some notes on starting to use Django
#35Earlier 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…
There is no way to autogenerate migrations that work in all cases. There are lots of things out there that can generate migrations that work for most simple cases.
That's why you can do your own migrations in Django for those edge cases.
Re: Some notes on starting to use Django
#36After 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.
If you're doing simple CRUD apps, try https://iommi.rocks/ which we built because imo it's way way too slow and produces too much code to use standard Django to make CRUD stuff.
Re: Some notes on starting to use Django
#37The Django ORM / migrations are still basically unmatched in happiness factor.
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…
There are some subtle edge cases in the django migrations where doing all the migrations at once is not the same as doing migrations one by one. This has bitten me on multiple django projects.
Re: Some notes on starting to use Django
#38> I love being able to backup by just doing a VACUUM INTO and then copying the resulting single file. Naively, I would probably just copy the sqlite file. Is that a bad idea?
That's fine if SQLite isn't running, but you risk corruption if you copy a file while it is being actively written to. VACUUM INTO eliminates that risk.
Thank you for mentioning this. I was planning to do exactly this soon and had no idea.
Re: Some notes on starting to use Django
#39The Django ORM / migrations are still basically unmatched in happiness factor.
Have you ever tried Rails? I think that Django's approach on those is an adaptation from it.
Re: Some notes on starting to use Django
#40The Django ORM / migrations are still basically unmatched in happiness factor.
oh the automatic migrations scare the bejesus out of me. i really prefer writing out schemas and migrations like in elixir/ecto. plus i like the option of having two different schemas for the same table (even if i never use it)
You can ask Django to show you what exact SQL will run for a migration using `manage.py sqlmigrate`.
You can run raw SQL in a Django migration. You can even substitute your SQL for otherwise autogenerated operations using `SeparateDatabaseAndState`.
You have a ton of control while not having to deal with boilerplate. Things usually can just happen automatically, and it's easy to find out and intervene when they can't.
https://docs.djangoproject.com/en/6.0/ref/django-admin/#djan...
https://docs.djangoproject.com/en/6.0/ref/migration-operatio...