Is having everything in Django models sensible?

Question

I've just inherited a Django project for maintenance and continuous development. While I'm a fairly proficient programmer (also Python) I have next to no experience with Django, therefore I need a bit of saneness-checking for my ideas ;)

The current problem is this: the project contains a custom install.sh file, which does three things:

1. Creating some non-model databases and importing initial data via SQL
2. Importing fixtures using manage.py
3. The usual migrate.py syncdb and migrate.py migrate.

(install.sh also contained some logic to implement half-baked south dependency management, which I replaced by a native one)

My idea was the following:

1. Generate models for every non-model database table (manage.py inspectdb for a start, split up in apps afterwards).
2. Convert all non-south models to south
3. Convert initial SQL data to south fixtures
4. Convert database backup routines to manage.py dumpdata (and restoring to manage.py loaddata fixtures).
5. Never work with raw SQL again

Now the simple question is: is this plan sensible? What are the alternatives?

Answer 1

Generate models for every non-model database table (manage.py inspectdb for a start, split up in apps afterwards).

Sounds good. You may want to proceed on a need-to-use basis on this though. Start with those you need immediately.

Convert all non-south models to south

I don't quite get what a non-south model is. If you mean generating south migrations for all existing models (and then probably --fake them during migration) then yes, this makes sense.

Convert initial SQL data to south fixtures

Again, what are South fixtures?

Convert database backup routines to manage.py dumpdata (and restoring to manage.py loaddata fixtures).

I am not so sure about this one. I have seen database specific backup and restore solutions used more frequently than manage.py. Especially if you have legacy triggers/stored procedures etc.

Never work with raw SQL again

Good in theory. Do keep in mind that you will at some point have to dig up SQL. As long as you don't use this as a reason to lose touch with SQL, or use it as an excuse not to get your hands "dirty" with SQL, then yes, go ahead.

Answer 2

Sounds sane enough to me, if you're after a pure no-actual-SQL route.

Two small points:

• the fixtures in 3) are actually Django fixtures, rather than South ones.
• using dumpdata to create JSON/XML Django fixtures and then restoring them is not without risks. Certain django.contrib apps (and many other non-contrib ones) can cause loaddata pain due to FK clashes etc, due to round-robin dependencies, etc. So, I would recommend dumping to SQL as well as fixtures. A raw SQL dump will be faster for a non-Djangonaut to restore if your server explodes while you're holidaying in the sun, etc