I’m soldiering on with trying to apply Django to my lolslackbot project, I thought I’d take a stab at letting Django try to use my existing database. My specific goal is to set up a read-only set of views on the primary social tables I have. People, Groups, Destinations all name entities in my system, I also have GroupMembership and Subscriptions tables which are many-to-many relations between the three primary tables. So far so good, at least for the primary tables; still working on the relations
Turns out starting with a legacy database isn’t too hard; you can use the inspectdb command to build skeletons of Django model classes from an existing database. Then hand-edit the resulting code. As a bonus this is an excuse for me to start learning more about Django models. Some random things I learned:
- Django model classes define both a database schema and the UI validation behavior in HTML forms.
- Every Django model class must have a primary key. The Python field is named “id”, not sure renaming it is possible or a good idea.
- A model can have the option “null” set to true or false; this is whether empty values are stored as nulls in the database. (Why would you ever not?!) There’s also a “blank” option which has nothing to do with the database, but is whether the field is optional in autogenerated forms like the admin interface.
- You have to hand-add each model class to admin.py to get it to show up in the admin interface.
- Django coding style is lowercase_with_underscores for field names, CamelCase for class names. ¿Porque no los dos?
That’s the easy stuff. On to hard stuff.
I’m not sure how to translate my existing many-to-many relations tables to however Django implements relationships. I thought maybe the extra fields support (using the through keyword argument) might do it, but that seems like overkill and possibly awkward. I think I need to just adapt the ManyToManyField to my existing schema.
I’m a little scared to let Django start writing data to my database.
inspectdb sets up things with managed = False by default. That seems wise; it prevents Django’s schema management stuff from messing with tables someone else defined already. But some day I’m going to want Django to take all this over for me, can I later change managed to True and make sense out of it?
I haven’t even begun to think about testing in the Django world. I know there’s a lot of support for tests, maybe that’s my next learning.