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
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
though the underscore means “don’t do this”). A full example is in the
aforementioned example program. Another trick:
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.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):