41–50 of 128 posts
Earlier quoted context omitted.
I've never done it, but now that you say it, it makes a lot of sense. Using Django just to manage the database and do migrations, even behind other language stacks. You also get the Django admin interface for free. I once tried using SqlAlchemy but I couldn't help asking myself why it felt so complicated compared to Django.
People who hate ORMs have just never tried Django :D
> Some light load testing (with (ab -n 1000 -c 1) shows that right now we can serve about 2-3 requests per second (on a ~$10/month VM). > After turning on template caching, it seems like the site can now pretty easily handle 12 requests per second or so without using all of the CPU. I have not carefully benchmarked the before and after but it seems like it’s made a pretty big difference. That seems crazy low, I think…
For Django's default template language, does it still have these limitations? 1. Brackets aren't allowed to help with boolean expressions like {% if a and (b or c) %} 2. You can't do basic arithmetic like {{ x * 2 }}, but you're allowed to do {{ x | add:"2" }}. There's hacks to multiply using {% widthratio a 1 b %} or division with {% widthratio a b 1 %} though ( https://stackoverflow.com/questions/18350630/multiplic…
> Is Jinja2 a practical alternative or there's friction to using it? jinja2 is drop in by changing the template backend. You can actually run both at the same time (just can't mix them, ofc). https://docs.djangoproject.com/en/6.0/topics/templates/
A few notables differences:
- many controls are now functions/variables (that's good!), and some change name, for example `{% csrf_token %}` -> `{{ csrf_input }}`
- calling methods without parenthesis does not work (that's good!), for example `query.all` -> `query.all()`
- in tests` response.context` is replaced by `response.context_data`, which is not set when calling `render` directly (need to return a proper `TemplateResponse`)
- template folders need to be renamed from `templates` to `jinja2`; there may be a way to change this behavior, but i did not find it, and this change is written so small in the docs i lost an entire day over it
Good ole Django. Worked with a number of frameworks (tm), but nothing really quite scratches my itch like Django does. I still find the ORM and database migration system unmatched.
I found Django a bit hard to get on with vs. other frameworks and I've used Rails, .NET MVC and Express (and friends). I just found more friction trying to achieve X for any given X for some reason. Not sure why.
Earlier quoted context omitted.
If you change an operation that is meant to return a Boolean to return anything else, you are insta fired.
I would have agreed with this, and then they did the `pathlib.Path` bit of cuteness with the `/` operator: https://github.com/python/cpython/blob/5afbb60e0283caaf34990... And despite my misgivings, it’s really ergonomic.
For Django's default template language, does it still have these limitations? 1. Brackets aren't allowed to help with boolean expressions like {% if a and (b or c) %} 2. You can't do basic arithmetic like {{ x * 2 }}, but you're allowed to do {{ x | add:"2" }}. There's hacks to multiply using {% widthratio a 1 b %} or division with {% widthratio a b 1 %} though ( https://stackoverflow.com/questions/18350630/multiplic…
The problem may be the lack of jinja support for 3rd party django apps (mostly legacy). So make sure they support it first.
I have been using Django since 0.95 and I haven't seen anything which is so flexible with amazing DSLs while also making it easy to understand the magic behind it. For the last 10 years, even in a Golang stack or Java stack, I still use Django for models and migration. I even have generators which generate Gorm (or other framework) DAO or Java hibernate classes using Django models. With LLMs, it becomes easier since…
> I still use Django for models and migration There are dozens of us! It's a great db management toolkit. I've used it to much success many times for things like managing migrations from mysql to postgres and php to python. My opinions: - Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries. I will die on this hill. No team is ever…
- Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries
Earlier quoted context omitted.
> I still use Django for models and migration There are dozens of us! It's a great db management toolkit. I've used it to much success many times for things like managing migrations from mysql to postgres and php to python. My opinions: - Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries. I will die on this hill. No team is ever…
- Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries Totally agree with this. Now we have thousands of unsquashable migrations that require a ton of work to fix.
Earlier quoted context omitted.
- Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries Totally agree with this. Now we have thousands of unsquashable migrations that require a ton of work to fix.
Can you share more on this? Is it better to keep all models in one app?
> Slicing up your project into apps is something that must be done early, often at the very start of development. This is a simple result of the fact that you need somewhere to put the code you're writing as you go along. In the early days and weeks of work on a new codebase, manage.py startapp gets used a lot, as the high-level structure of the project starts to take shape.
> The issue here is that at this early stage, you often don't really know enough about what the project's final form will look like to correctly draw the boundaries around the apps. Functionality that feels separate at first often becomes deeply entangled, and features that sound similar end up sharing little. Over time, the key concepts and models in your system become clear, and if these are colocated with unrelated or irrelevant code, the waters of the project become muddy and maintenance becomes difficult - before the project is even in production!
> While it is technically possible to migrate models between apps, Django doesn't make it easy, particularly if the models in question have foreign key or many-to-many relationships with other models. And if you think about it, it's not really a technical limitation of the sort that could easily be solved with a PR into Django. It's a conceptual problem: if migrations are a historical record of changes to models, and migrations are encapsulated in the same app as those models, then moving a model to a different app necessarily creates a historical coupling between the two apps that shouldn't really exist.