Taming runtime dynamic models in django - Will Hardy (djangocon.eu)¶

Tags: djangocon, django

He works for ammonit and he has to deal with wind speed loggers for determining the optimal location for wind energy parks. The sensors get bigger and more advanced and so the previously-fine sql tables were filling up FAST.

An optimization could be to give every logger its own table (or its own column). But then you need run-time dynamic models as a fresh table or column isn’t defined in your models.py, of course, as extra wind loggers can be added all the time.

He’s got an example at https://github.com/willhardy/dynamic-models so you can look at the actual code.

For creating and deleting tables/columns he uses south. South has methods you can use directly. db.create_table() and so. Django has a couple of tools for table introspection. Those were enough for his needs. See django.db.connection.introspection .

Those from-the-code migration steps are not something that runs when running a syncdb or a migrate. He uses the class_prepared signal to do it anyway at the right point in time. You can also hook into the site._registry (even though the underscore means “don’t do this”). A full example is in the aforementioned example program. Another trick: clear_url_caches() from django.core.urlresolvers. This reloads certain items to prevent django from getting too confused when new models “suddenly” appear.

Note that, whenever possible, you should just use regular normalized databases. Only use this approach in those few rare cases where it applies. Other options are sparse tables or NoSQL or pseudoanonymous columns.