Management command sqlall should support unmanaged models

[jarshwah]

Unmanaged models are generally used with legacy database tables, but creating those models in a development environment is also a manual process. It'd be great if django was able to produce the sql for managed models if explicitly asked for.

loic84, akaariai and I discussed this in IRC and came up with:

./manage sqlall applabel --include-unmanaged

The include unmanaged would print the sql necessary to create the unmanaged models (along with the sql for the other models in that app).

[mardini]

After a discussion on IRC, Tim suggested closing this ticket and not doing any new work on sql commands, since they will be deprecated according to Andrew: https://code.djangoproject.com/ticket/22611#comment:6

[loic84]

@mardini, these commands going away doesn't change the fact that we don't have an answer to the problem of generating SQL for unmanaged models.

I think the feature request still stands even if it'll have to go through a different path than sqlall.

[Shai Berger]

May I suggest a workaround:

1. Edit your app models, comment out the "managed=False" lines.
2. Use sqlall, save output.
3. Restore models.

Now you have a sql file you can use instead of manual labor.

Or, if you're terribly worried about forgetting to restore the models --

1. Start a new project. Direct it to a database that has the tables.
2. startapp
3. inspectdb
4. sqlall
5. Throw away the project.

This can even be done in a script, in case your unmanaged models change and you need to re-do this often.

This one actually points in the direction of a possible solution -- it could be a flag on the inspectdb command (--sql or some such).

[jarshwah]

I don't think either of those workarounds are particularly good. We discussed setting managed=False as a temporary solution, but that can be cumbersome, and has to be repeated by every dev (unless you copy the output to a new script..). Your second solution also requires devs to have direct access to the production database, and possibly one that has a lot more in it then a single table that you just want to output sql for.

For my specific use-case I have materialised views and views in the production database (managed=False), but want to create tables that match the definition in the development database. These definitions may change over time, so inspectdb --sql isn't really what I'm after. And with the sql commands going away, I'm not sure how switching the managed setting temporarily is going to work with migrations.

[Aman Pandey]

since sqlall has been deprecated , should we need to build a new command or add the feature on existing one?