You should be able to interpret db_table=None as 'don't create table' without too much trouble.Longer term, it would be nice to have support for creating views... View implemented once, but replaced it again, by the simpler approach posted here.
This option is much better concerning separation of concerns and maintenance see here no need to follow the link above, this is the copy/pasted text: what we did first was implementing just normal models in the models.py, but that always created the tables in the DB upon “syncdb” (which we deleted then and created views for).
Actually I even wrote a patch for django where you can mark a model as “create_table=False” but the patch never made it in.
So we went another actually much better way, after discussing it a lot in the team.
I am using DB-views but also want them to be available as a model inside the app, but I dont want "syncdb" to create any DB table for it.
So I added an option "create_db_table" to the Meta class, like so: Unless I'm misunderstanding, this is moot; you don't have to run syncdb if you don't want to (you can instead create the DB tables and views yourself, and then lay out model classes to match).
If I've misread what you're asking for, please re-open this. This meta attribute is just for NOT creating a DB table for a certain model (which is not the default! I have created the model (in model.py) so I can access the view from within django too, but syncdb shall not create anything when being run, I am creating the view directly via SQL.Letting syncdb create the DB table would just clash with the creation of the view by SQL and would be useless (in my case). Model): id = Auto Field() name = Char Field() since = Date Time Field() class Users2006(models.Model): """This is just a view on the users table but only for the users of the year 2006, that is done by using a DB view, so no need for creating a db table.""" id = Auto Field() name = Char Field() since = Date Time Field() class Meta: create_db_table = False # prevent table creation in DB I don't have much use for this myself, but I like the idea.Extra kudos for delivering the whole package (documentation and all).However, I would lean towards using the existing db_table variable, rather than introducing a new one.