Certifique-se de que a configuração DEBUG está definida como True. Então, apenas faça isso:
>>> from django.db import connection
>>> connection.queries
[{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date FROM polls_polls',
'time': '0.002'}]
connection.queries está disponível apenas se DEBUG for True. É uma lista de dicionários na ordem de execução das consultas. Cada dicionário tem o seguinte:
``sql`` -- A declaração SQL
``time`` -- O tempo que a declaração levou para executar, em segundos.
connection.queries inclui todas as declarações SQL -- INSERTs, UPDATES, SELECTs, etc. Cada vez que o seu app aciona o banco de dados, a consulta será gravada. Note que os SQL brutos logados em connection.queries podem não incluir os parâmetros entre aspas. A colocação de aspas nos parâmatros é executada pelo backend específico de banco de dados, e nem todos os backends fornecem uma forma de obter o SQL depois de colocadas as aspas.
Se você está usando múltiplos bancos de dado, você pode usar a mesma interface em cada membro do dicionário connections:
>>> from django.db import connections
>>> connections['my_db_alias'].queries
Sim. Veja Integrando com um banco de dados legado.
Se você não se importar em "resetar" os dados, o utilitário manage.py do seu projeto tem uma opção para resetar o SQL para uma aplicação em particular:
manage.py reset appname
Isso apaga quaisquer tabelas relacionadas com o appname e as recria.
Se você se importa sobre a remoção dos dados, você tem de executar as declarações ALTER TABLE manualmente no seu banco de dados. Esse é o modo que nós sempre fizemos, porque lidar com dados é uma operação muito sensível e nós procuramos evitar sua automatização. Dito isso, existem trabalhos sendo feitos para adicionar a funcionalidade de atualização automatizada de banco de dados de forma parcial.
Não. Apenas chaves primárias simples são suportadas.
Mas isso não é um problema na prática, já que nada o impede de adicionar outras restrições (usando a opção do model unique_together ou criando a restrição diretamente no seu banco de dados) garantindo a unicidade nesse nível. Chaves primárias simples são necessárias para que coisas como a interface administrativa funcione; por exemplo, você precisa de uma forma simples de ser capaz de especificar um objeto para editar ou remover.
Nós tentamos evitar casos especiais no código do Django para acomodar todas as opções específicas de banco de dados, como tipo da tabela, etc. Se você gostaria de usar essa opções, crie um arquivo de dados SQL inicial que contenha as declarações ALTER TABLE que você quer fazer. Os arquivos de dados iniciais são executados no seu banco de dados após as declarações CREATE TABLE.
Por exemplo, se você está usando o MySQL e quer que suas tabelas sejam do tipo MyISAM, crie um arquivo de dados iniciais e coloque algo assim dentro dele:
ALTER TABLE myapp_mytable ENGINE=MyISAM;
Como explicado na documentação do arquivo de dados SQL inicial , esse arquivo SQL pode conter comandos SQL arbitrários, assim você pode fazer quaisquer modificações que quiser nele.
O Django não é conhecido por vazar memória. Se você descobrir que seus processos Django estão alocando mais e mais memória, sem nenhum sinal de liberação, verifique se o DEBUG está definido como False. Se o DEBUG for True, então o Django salvará uma cópia de cada declaração SQL que ele executou.
(As consultas são salvas em django.db.connection.queries. Veja Como eu posso ver as consultas SQL que o Django está executando?.)
Para resolver esse problema, defina o DEBUG como False.
Se você precisa limpar a lista de consultas manualmente em qualquer ponto das suas funções, apenas execute reset_queries(), assim:
from django import db
db.reset_queries()
Dec 26, 2011