Make sure your Django DEBUG setting is set to True.\nThen, just do this:
>>> from django.db import connection\n>>> connection.queries\n[{'sql': 'SELECT polls_polls.id, polls_polls.question, polls_polls.pub_date FROM polls_polls',\n'time': '0.002'}]\nconnection.queries is only available if DEBUG is True.\nIt’s a list of dictionaries in order of query execution. Each dictionary has\nthe following:
``sql`` -- The raw SQL statement\n``time`` -- How long the statement took to execute, in seconds.\nconnection.queries includes all SQL statements – INSERTs, UPDATES,\nSELECTs, etc. Each time your app hits the database, the query will be recorded.
If you are using multiple databases, you can use the\nsame interface on each member of the connections dictionary:
>>> from django.db import connections\n>>> connections['my_db_alias'].queries\nIf you need to clear the query list manually at any point in your functions,\njust call reset_queries(), like this:
from django.db import reset_queries\nreset_queries()\nYes. See Integrating with a legacy database.
\nTake a look at Django’s support for schema migrations.
If you don’t mind clearing data, your project’s manage.py utility has a\nflush option to reset the database to the state it was in\nimmediately after migrate was executed.
No. Only single-column primary keys are supported.
\nBut this isn’t an issue in practice, because there’s nothing stopping you from\nadding other constraints (using the unique_together model option or\ncreating the constraint directly in your database), and enforcing the\nuniqueness at that level. Single-column primary keys are needed for things such\nas the admin interface to work; e.g., you need a simple way of being able to\nspecify an object to edit or delete.
NoSQL databases are not officially supported by Django itself. There are,\nhowever, a number of side project and forks which allow NoSQL functionality in\nDjango, like Django non-rel.
\nYou can also take a look on the wiki page which discusses some alternatives.
\nWe try to avoid adding special cases in the Django code to accommodate all the\ndatabase-specific options such as table type, etc. If you’d like to use any of\nthese options, create a migration with a\nRunSQL operation that contains\nALTER TABLE statements that do what you want to do.
For example, if you’re using MySQL and want your tables to use the MyISAM table\ntype, use the following SQL:
\nALTER TABLE myapp_mytable ENGINE=MyISAM;\n