Is it a bad idea to change the app_label assignment on existing Django models?

I have the hair-brained idea of grouping models from different existing apps into one big new shiny app.开发者_如何学C There's not a super important reason I need to do this, but it would be nice to consolidate all of the code in one subdirectory and it would improve the site to group all the models together in the admin_index under the same module header.

My first thought was to hardcode the existing table names into the db_table setting in Meta on all the models, and then give each an identical app_label setting.

But my concern is that this might screw up the ContentType and auth Permission settings for everything. Has anyone tried this before? I've googled around a bit and haven't seen anything that directly the addresses the question, though it seems like a few people have come up with slick ways of reorginizing the admin_index with some custom configuration settings.

You're correct that moving models around would render existing ContentType entries useless. Without knowing the specifics of your project it's hard to say what might be a "good idea". You might just try branching your code, making the changes, and updating the content types and permissions tables to reflect. Alternatively you could use South to write a data migration although it could be tricky to find a balance of making it work depending on when the migration is created or run vs. when you move the models. You might also check out natural keys if you're able to run trunk: http://docs.djangoproject.com/en/dev/topics/serialization/#natural-keys. This could lead to an easier path of exporting your data out into fixtures in a more generic manner so that once you make your changes you be able to load them in without too much difficulty.

If you're planning on using Django for a while and/or working on large projects you'll want to start to develop the skills to deal with these types of changes. Evolving code and refactoring are facts of life. Learning about the pitfalls of making these changes in a casual setting will set you up better for the future to tackle the kinds of issues that do occur in team settings and on larger projects.