Django - first data!

With Django installed it was a question of seeing if I could get data out of the wow.gedsguides.com database. So I munged the table definition parts of my database build (structure) script, create.sql, into a Django-style model definition in a new model.py. OK, so I only did two of the tables, but it's the thought that counts.

Then just a matter of validating the models using Django's built-in manage.py tool, and once I'd fixed a couple of newbie bugs I looked at the generated sql, and it was certainly close enough to the original DDL in create.sql for me to be confident that the Django models were going to work with the existing database just fine.

Then it was time to go into the webmin interface of the new (soon-to-be-migrated-to) virtual server running on a box in jsp-servlet.net's data centre somewhere in San Francisco and tell postgres to let my home PC connect to the database.

Then an SSH session into the same virtual server, to run the actual database creation script — my original create.sql, naturally. I wasn't going to run the Django one for the pretty obvious reason that other applications have to be able to work with this database, so Django just can't be the lord and master there.

Once that was all done I tested connection from my home PC to the remote database by running pgAdmin III and that was fine, so I edited my new Django app's settings to tell it how to connect up, and then it was time to go into manage.py's interactive shell and start instantiating database objects:

>>> from ggw.admin.models import Stages
>>> qs = Stages.objects.all()
>>> print [p.name for p in qs]
[u'Stub', u'Notes', u'Rough draft', u'Final draft', u'Complete']
>>> print [p.id for p in qs]
[10, 25, 50, 75, 99]

Tomorrow I'll look at what it's come up with in the way of an automatically generated admin interface, and at that point I'll know whether I want to proceed or not.

Some things do stand out though. The rather ad-hoc nature of Django's query filter language being one. I don't know, it may be modelled on some absolutely standard object query language (I don't like them either) but it seems to have had to replicate, in an amazingly clunky and obtuse way, what you get as a nice, clear syntax in SQL itself. For example, I don't know how anyone can think that a where-clause expressed like this:

Entry.objects.filter(pub_date__lte='2006-01-01')

is an improvement on one expressed like this:

SELECT * FROM blog_entry WHERE pub_date <= '2006-01-01';

"Publication date less than or equal to equals some date" ... I don't know — how do you read that in a way that doesn't insult your linguistic sensibility? But obviously it's what you have to do when you have all that enormous object-relational machinery in the way. (It reminds me of the old saw about all applications evolving until they include a complete lisp interpreter, implemented very badly.)

---

Update: Sheesh, them thar interwebs are humbling things: no sooner do I write my half-baked objections in the last few paragraphs above, than I stumble — from a completely different direction — on someone making exactly the same point, a hundred times better, in a different-but-comparable context.