5 ms·
I've been using Django on and off at work for the past few years. I really like it. That being said, I still find its ORM difficult. I understand it now that si
by aynyc 9mo ago
I've been using Django on and off at work for the past few years. I really like it. That being said, I still find its ORM difficult. I understand it now that since it's an opinionated framework, I need to follow Django way of thinking. The main issue is that at work, I have multiple databases from different business units. So I constantly have to figure out a way to deal with multiple databases and their idiosyncrasies. I ended up doing a lot of hand holding by turning off managed, inspectdb and then manually delete tables I don't want to show via website or other reasons. For green webapps we have, django is as good as it gets.
- melvinroest 9mo agoMaybe this shows my data analyst tendencies, but why not use SQL?
- aynyc 9mo agoThat’s what we do now. But it gets repetitive and not leveraging Django core features.
- JodieBenitez 9mo agoDo you use Django's multiple databases support ? (https://docs.djangoproject.com/en/6.0/topics/db/multi-db/ https://docs.djangoproject.com/en/6.0/topics/db/multi-db/)
- aynyc 9mo agoYes, we have to in order to use a lot of the features. The core issue for us is really the way Django assumes code represents database state. In normal webapp where the application has full control of the database, that's a good idea. But our databases are overloaded for simple transactions, analytics, users managements, jobs and AI. Business uses the databases in various ways such as Power BI, Aquastudio, etc.. Django app is actually a tiny part of the database. As you can imagine, we duck tape the heck out of the databases, and Django goes bonkers when things aren't matching.
- sgt 9mo agoAlso don't underestimate setting up e.g. views or materialized views even that you can use through the ORM to query. It helps a lot and allows you to combine fine tuning SQL with ease of use through Django, and get a lot of performance out of it. Just remember to create them in the migration scripts.
- aynyc 9mo agoAny docs? Django migration is a HUUGE pain point for us.
- WesleyJohnson 9mo agomanage.py makemigrations myapp --empty --name add_some_view (in the migration file) operations=[migrations.RunSQL("Create View some_view AS ....", "DROP VIEW IF EXISTS...."] (in your models.py) class SomeView(models.Model): class Meta: db_table = 'some_view' managed = False manage.py makemigrations myapp --name add_some_view_model
- sgt 9mo agoAn extremely common thing to do. Also great with materialized views. I bet it's documented somewhere in Django's docs.
- luxcem 9mo agoI've been using Django for the last 10+ years, its ORM is good-ish. At some point there was a trend to use sqlalchemy instead but it was not worth the effort. The Manager interface is also quite confusing at first. What I find really great is the migration tool.
- formerly_proven 9mo agoSince Django has gained mature native migrations there is a lot less point to using SQLAlchemy in a Django project, though SQLAlchemy is undeniably the superior and far more capable ORM. That should be unsurprising though - sqlalchemy is more code than the entire django package, and sqlalchemy + alembic is roughly five times as many LOC as django.db, and both are similar "density" code.
- WD-42 9mo agoMakes sense as sqlalchemy’s docs are also 5x as confusing.
- dontlaugh 9mo agoI've used Aldjemy (https://github.com/aldjemy/aldjemy https://github.com/aldjemy/aldjemy) on a small project and it worked pretty well for allowing me to compose the fairly complex queries needed that the Django ORM couldn't do.
- BowBun 9mo agoAgreed, and their DB migration workflow leaves much to be desired. By not storing a schema/DB state alongside code, Django depends on the current DB state to try and figure it out from scratch every time you run a DB command. Not to mention defining DB state from model code is inherently flawed, since models are abstractions on top of database tables. I much prefer the Rails way of composing migrations as specific DB instructions, and then getting models 'for free' on top of those tables.