←back to thread

378 points rbanffy | 3 comments | | HN request time: 0.961s | source
Show context
aynyc ◴[] No.46217665[source]
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.
replies(6): >>46217950 #>>46218252 #>>46218271 #>>46218403 #>>46218484 #>>46218923 #
sgt ◴[] No.46218271[source]
Also 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.
replies(1): >>46219777 #
1. aynyc ◴[] No.46219777[source]
Any docs? Django migration is a HUUGE pain point for us.
replies(1): >>46220686 #
2. WesleyJohnson ◴[] No.46220686[source]

  manage.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
replies(1): >>46222670 #
3. sgt ◴[] No.46222670[source]
An extremely common thing to do. Also great with materialized views. I bet it's documented somewhere in Django's docs.