.. .. META INFORMATION OF TRANSLATION .. .. $TranslationStatus: Done $ .. $OriginalRevision: 11268 $ .. $TranslationAuthors: Robson Mendonça, semente $ .. .. INFO OF THIS FILE (DO NOT EDIT! UPDATED BY SUBVERSION) .. .. $HeadURL: http://django-l10n-portuguese.googlecode.com/svn/branches/docs-1.0.X/ref/django-admin.txt $ .. $LastChangedRevision: 599 $ .. $LastChangedBy: semente $ .. $LastChangedDate: 2009-11-12 17:09:40 -0200 (Thu, 12 Nov 2009) $ .. .. _ref-django-admin: =========================== django-admin.py e manage.py =========================== ``django-admin.py`` é o utilitário de linha de comando do Django para tarefas administrativas. Este documento contempla tudo que ele pode fazer. Além disso, ``manage.py`` é automaticamente criado em cada projeto Django. O ``manage.py`` é um wrapper simples em volta do ``django-admin.py`` que se preocupa com duas coisas por você antes de delegar tarefas ao ``django-admin.py``: * Ele coloca o pacote do seu projeto no ``sys.path``. * Ele define a variável de ambiente :envvar:`DJANGO_SETTINGS_MODULE` que então aponta para o arquivo ``settings.py`` do seu projeto. O script ``django-admin.py`` deve estar no *path* do seu sistema se você instalou o Django via o utilitário ``setup.py``. Se não estiver no seu *path*, você pode encontrá-lo dentro da sua instalação Python em ``site-packages/django/bin``. Considere criar um link simbólico para ele no *path* do seu sistema, como ``/usr/local/bin``. Para usuários Windows, que não possuem a funcionalidade de link simbólico disponível, você pode copiar o ``django-admin.py`` para um local existente em seu *path* ou editar as configurações de ``PATH`` (sob ``Configurações - Painel de Controle - Sistema - Avançado - Ambiente...``) para apontar para o local instalado. Geralmente, quando se trabalha com um único projeto Django, é mais fácil usar o ``manage.py``. Usar o ``django-admin.py`` com ``DJANGO_SETTINGS_MODULE``, ou a opção de linha de comando ``--settings``, se você precisar trocar entre vários arquivos settings do Django. Os exemplos de linha de comando de todo este documento usa o ``django-admin.py`` para ser consistente, mas qualquer exemplo pode usar o ``manage.py`` da mesma forma. Uso === .. code-block:: bash django-admin.py [options] manage.py [options] ``subcommand`` deve ser um dos subcomandos listados neste documento. ``options``, que é opcional, deve ser zero ou mais das opções disponíveis para um dado subcomando. Obtendo ajuda em tempo de execução ---------------------------------- .. django-admin-option:: --help Execute ``django-admin.py help`` para mostrar uma lista de todos os subcomandos disponíveis. Execute ``django-admin.py help `` para mostrar uma descrição do subcomando em questão e uma lista de suas opções disponíveis. App names --------- Muitos subcomandos recebem uma lista de "app names". Um "app name" é o nome básico do pacote contento seus models. Por exemplo, se sua ``INSTALLED_APPS`` contém a string ``'mysite.blog'``, o *app name* é ``blog``. Determinando a versão --------------------- .. django-admin-option:: --version Execute ``django-admin.py --version`` para mostra a versão atual do Django. Exemplos de saídas:: 0.95 0.96 0.97-pre-SVN-6069 Mostrando saída de debug ------------------------ .. django-admin-option:: --verbosity Use ``--verbosity`` para especificar o montante de notificações e informações de debug que ``django-admin.py`` deve imprimir no console. * ``0`` significa nenhuma saída. * ``1`` significa saída normal (padrão). * ``2`` significa saída prolixa. Subcomandos disponíveis ======================= cleanup ------- .. versionadded:: 1.0 Pode ser executado como um cronjob ou diretamente para limpar dados antigos do banco de dados (somente sessões expiradas até o momento). compilemessages --------------- .. versionchanged:: 1.0 Antes do 1.0 este era o comando "bin/compile-messages.py". Compila arquivos .po criados com ``makemessages`` para arquivos .mo para uso com o suporte embutido ao gettext. Veja :ref:`topics-i18n`. --locale ~~~~~~~~ Use as opções ``--locale`` ou ``-l`` para especificar o locale a ser processado. Se você não especificá-lo, todos os locales são processados. Exemplo de uso:: django-admin.py compilemessages --locale=pt_BR createcachetable ---------------- .. django-admin:: createcachetable Cria uma tabela de cache com o nome ``tablename`` para uso com o *backend* de cache em banco de dados. createsuperuser --------------- .. django-admin:: createsuperuser .. versionadded:: 1.0 Cria uma conta de superusuário (um usuário que tem todas as permissões). Isso é útil se você precisa criar uma conta inicial de superusuário, mas não o fez durante o ``syncdb``, ou se você precisa programaticamente gerar contas de superusuário para seu(s) site(s). Quando executar interativamente, este comando pedirá uma senha para a nova conta de super usuário. Quando executá-lo de forma não interativa, nenhuma senha será definida, e a conta de superusuário não será hábil a logar-se até que uma senha seja manualmente definida para ele. .. django-admin-option:: --username .. django-admin-option:: --email O nome de usuário e endereço de e-mail para a nova conta podem ser fornecidos usando os argumentos ``--username`` e ``--email`` na linha de comando. Se algum deles não forem fornecidos, ``createsuperuser`` pedirá por eles quando estiver rodando interativamente. Este comando estará disponível somente se o :ref:`sistema de autenticação ` do Django (``django.contrib.auth``) estiver instalado. dbshell ------- .. django-admin:: dbshell Executa o cliente de linha de comando para o *engine* de banco de dados especificado em sua configuração ``DATABASE_ENGINE``, com os paramêtros de conexão especificados em ``DATABASE_USER``, ``DATABASE_PASSWORD``, etc. * Para PostgreSQL, rodará o cliente de linha de comando ``psql``. * Para MySQL, rodará o cliente de linha de comando ``mysql``. * Para SQLite, rodará o cliente de linha de comando ``sqlite3``. Este comando assume que os programas estão no seu ``PATH``, de modo que uma simples chamada pelo nome do programa (``psql``, ``mysql``, ``sqlite3``) encontrará o programa no lugar certo. Não há formas de especificar a localização do programa manualmente. diffsettings ------------ .. django-admin:: diffsettings Mostra diferenças entre as configurações atuais e as padrões do Django. Configurações que não aparecem nas padrões são seguidas por ``"###"``. Por exemplo, a configuração padrão não define ``ROOT_URLCONF``, então o ``ROOT_URLCONF`` é seguido de ``"###"`` na saída do ``diffsettings``. Note que as configurações padrões do Django estão em ``django/conf/global_settings.py``, se você estiver curioso para ver a lista completa delas. dumpdata -------- .. django-admin:: dumpdata Mostra na saída padrão todos os dados no banco de dados associado às aplicações listadas. Se nenhum nome de aplicação é fornecido, todas as aplicações instaladas serão extraídas. A saída de ``dumpdata`` pode ser usada como entrada para ``loaddata``. Note que ``dumpdata`` usa o *manager* padrão do model para selecionar os registros a serem exportados. Se você estiver usando um :ref:`manager personalizado ` como manager padrão e ele filtra algumas entradas disponíveis, nem todos os objetos serão exportados. .. django-admin-option:: --exclude .. versionadded:: 1.0 Excluí uma aplicação específica das aplicações cujo conteúdo é mostrado. Por exemplo, para especificadamente excluir a aplicação `auth` da saída, você deve chamar:: django-admin.py dumpdata --exclude=auth Se você deseja excluir várias aplicações, use várias diretivas ``--exclude``:: django-admin.py dumpdata --exclude=auth --exclude=contenttypes .. django-admin-option:: --format Por padrão, ``dumpdata`` formatará sua saída como JSON, mas você pode usar a opção ``--format`` para especificar outro formato. Os formatos atualmente suportados estão listados em :ref:`serialization-formats`. .. django-admin-option:: --indent Por padrão, ``dumpdata`` exportará todos os dados em uma única linha. Isso não é fácil para humanos lerem, então você pode usar a opção ``--indent`` para imprimir uma bela saída com alguns espaços de indentação. flush ----- .. django-admin: flush Retorna o banco de dados ao estado em que ele estava imediatamente após a execução do syncdb. Isto significa que todos os dados serão removidos do banco de dados, quaisquer manipuladores de sincronização posterior, serão re-executados, e o fixture ``initial_data`` será reinstalado. .. django-admin-option:: --noinput Use a opção ``--noinput`` para suprimir todo prompt para o usuário, como as mensagens de confirmação "Você tem certeza?". Isso é útil se o ``django-admin.py`` é executado como um script autônomo. inspectdb --------- Faz introspecção nas tabelas do banco de dados apontado pela configuração ``DATABASE_NAME`` e mostra um módulo de model do Django (um arquivo ``models.py``) na saída padrão. Use isso se você tem um banco de dados legado com o qual você gostaria de usar o Django. O script irá inspecionar o banco de dados e criar um model para cada tabela dentro dele. Como você pode esperar, os models criados terão um atributo para todos os campos da tabela. Note que ``inspectdb`` tem uns poucos casos especiais em sua saída de nomes de campos: * Se ``inspectdb`` não mapear um tipo de coluna para o tipo de campo do model, ele usará um ``TextField`` e inserirá um comentário Python ``'This field type is a guess'`` (traduzindo, ``'Este tipo de campo é uma advinhação'``.) próximo ao campo gerado no model. * Se o nome da coluna do banco de dados é uma palavra reservada do Python (tipo ``'pass'``, ``'class'`` ou ``'for'``), o ``inspectdb`` adicionará ``'_field'`` ao nome do atributo. Por exemplo, se uma tabela tem uma coluna ``'for'``, o model gerado terá um campo ``'for_field'``, com o atributo ``db_column`` setado para ``'for'``. O ``inspectdb`` inserirá o comentário Python ``'Field renamed because it was a Python reserved word'`` (traduzindo, ``'Campo renomeado porque é uma palavra reservada do Python'``) próximo ao campo. Esta funcionalidade é para ser um atalho, não um gerador de models definitivo. Depois que você rodá-la, você precisará mexer nos models para personalizá-lo. Em particular, você precisará reorganizar a ordem dos models, desta forma os models que são referenciados por outros, funcionarão apropriadamente. Chaves primárias são automaticamente introspectadas no PostgreSQL, MySQL e SQLite, nestes casos o Django coloca ``primary_key=True`` onde for necessário. O ``inspectedb`` trabalha com PostgreSQL, MySQL e SQLite. Detecção de chaves estrangeiras somente funcionam no PostgreSQL e com certos tipos de tabelas do MySQL. loaddata ------------------------------ Procura e carrega os conteúdos de fixtures para dentro do banco de dados. Um *fixture* é uma coleção de arquivos que contém os conteúdos serializados do banco de dados. Cada fixture tem um nome único, e os arquivos que compreendem aos fixtures podem estar distribuídos em vários diretórios, em várias aplicações. O Django procurará em três lugares por fixtures: 1. No diretório ``fixtures`` de cada aplicação instalada 2. Em qualquer diretório encontrado na configuração ``FIXTURE_DIRS`` 3. No caminho literal nomeado para o fixture O Django carregará qualquer e todos os fixtures que encontrar, nos lugares que combinarem com os nomes de fixtures fornecidos. Se o fixture nomeado tem uma extensão de arquivo, somente fixtures daquele tipo serão carregados. Por exemplo:: django-admin.py loaddata mydata.json poderia somente carregar fixtures JSON chamados ``mydata``. A extensão do fixture deve corresponder ao nome registrado do serializador (e.g., ``json`` ou ``xml``). Se você omitir a extensão, o Django procurará todos os tipos de fixtures disponíveis até encontrar uma combinação. Por exemplo:: django-admin.py loaddata mydata poderia procurar por qualquer fixture de qualquer tipo chamado ``mydata``. Se um diretório de fixture contendo ``mydata.json``, cujo a fixture poderia ser carregada como uma fixture JSON. Entretanto, se duas fixtures com o mesmo nome mas tipos diferentes forem descobertas (por exemplo, se ``mydata.json`` e ``mydata.xml`` fossem encontradas em algum diretório de fixtures), a instalação do fixtures será abortada, e qualquer dado instalado na chamada do ``loaddata`` será removido do banco de dados. Os fixtures que são nomeados podem incluir componentes de diretório. Estes diretórios serão incluídos no caminho de busca. Por exemplo:: django-admin.py loaddata foo/bar/mydata.json poderia procurar ``/fixtures/foo/bar/mydata.json`` para cada aplicação instalada, ``/foo/bar/mydata.json`` para cada diretório no ``FIXTURE_DIRS``, e o caminho literal ``foo/bar/mydata.json``. Quando arquivos fixture são processados, os dados são salvos no banco de dados como estão. O método ``save`` do model definido e o sinal ``pre_save`` não são chamados. Note que a ordem em que os arquivos de fixtures são processados é indefinida. Entretanto, todos os dados são instalados como uma transação única, então, dados de uma fixture podem referenciar dados de outra fixture. Se o backend de banco de dados suporta constraints a nível de linha, estes constraints serão checados no final da transação. O comando ``dumbdata`` pode ser usado para gerar entrada para ``loaddata``. .. admonition:: MySQL e Fixtures Infelizmente, o MySQL não é capaz de suportar completamente todas as funcionalidades dos fixtures do Django. Se você usa tabelas MyISAM, o MySQL não suporta transações ou constraints, então você não pode fazer um rollback se vários arquivos de transação são encontrados, ou fixtures com dados de validação.Se você usa tabelas InnoDB, você não poderá ter qualquer referência nos seus arquivos de dados - o MySQL não provê um mecanismo para diferir checagens de constraints de linhas até que uma transação seja comitada. --verbosity ~~~~~~~~~~~ Use ``--verbosity`` para especificar o quanto de notificações e informações de debug o ``django-admin.py`` deverá imprimir no console. * ``0`` significa nenhuma saída. * ``1`` significa saída normal (padrão). * ``2`` significa saída prolixa. Exemplo de uso:: django-admin.py loaddata --verbosity=2 makemessages ------------ .. versionchanged:: 1.0 Antes da versão 1.0 este era o comando ``bin/make-messages.py``. Executa sobre toda árvore de código do diretório atual e extrai todas as *strings* marcadas para tradução. Ele cria (ou atualiza) um arquivo de mensagem em conf/locale (na árvore do django) ou um diretório locale (para o projeto e aplicação). Depois de fazer as mudanças nos arquivos de mensagens você precisará compilá-los com ``compilemessages`` para usar com o suporte ao gettext embutido. Veja :ref:`a documentação i18n ` para detalhes. --all ~~~~~ Use as opções ``--all`` ou ``-a`` para atualizar os arquivos de mensagens para todas os idiomas disponíveis. Exemplo de uso:: django-admin.py makemessages --all --extension ~~~~~~~~~~~ Use as opções ``--extension`` ou ``-e`` para especificar uma lista de extensões de arquivos para examinar (padrão: ".html"). Exemplo de uso:: django-admin.py makemessages --locale=de --extension xhtml Separe as várias extensões com vírgulas ou usando -e ou --extension várias vezes:: django-admin.py makemessages --locale=de --extension=html,txt --extension xml --locale ~~~~~~~~ Use as opções ``--locale`` ou ``-l`` para especificar o locale a ser processado. Exemplo de uso:: django-admin.py makemessages --locale=pt_BR --domain ~~~~~~~~ Use as opções ``--domain`` ou ``-d`` para mudar o domínio dos arquivos de mensagens. Atualmente são suportados: * ``django`` para todo arquivo ``*.py`` e ``*.html`` (padrão) * ``djangojs`` para arquivos ``*.js`` --verbosity ~~~~~~~~~~~ Use ``--verbosity`` para especificar o quanto de notificações e informações de debug o ``django-admin.py`` deverá imprimir no console. * ``0`` significa nenhuma saída. * ``1`` significa saída normal (padrão). * ``2`` significa saída prolixa. Exemplo de uso:: django-admin.py makemessages --verbosity=2 reset --------------------------- Executa o equivalente a ``sqlreset`` para uma app específica. --noinput ~~~~~~~~~ Use a opção ``--noinput`` para suprimir todo prompt ao usuário, como mensagens de confirmação "Você tem certeza?". Isso é útil se o ``django-admin.py`` for executado de forma autônoma, por um script. runfcgi [options] ----------------- Inicia um conjunto de processos FastCGI adequados para uso com qualquer servidor Web que suporta o protocolo FastCGI. Veja a :ref:`documentação de implantação no FastCGI ` para detalhes. Requer o módulo FastCGI do Python `flup`_. .. _flup: http://www.saddi.com/software/flup/ runserver --------- .. django-admin:: runserver [port or ipaddr:port] Inicia um servidor Web leve de desenvolvimento na máquina local. Por padrão, o servidor roda na porta 8000 no endereço IP 127.0.0.1. Você pode passar um endereço IP e uma porta explicitamente. Se você executar este script como um usuário com privilégios normais (recomendado), você pode não ter permissão para poder iniciar o servidor numa porta de número baixo. Portas de números baixos são reservadas ao super-usuário (root). NÃO USE ESTE SERVIDOR EM AMBIENTE DE PRODUÇÃO. Ele não passou por auditorias de segurança ou testes de desempenho. (E isso vai ficar como está. Nosso negócio é fazer um framework Web, não servidores Web, portanto, improvisar este servidor para torná-lo usável em ambiente de produção está fora do escopo do Django.) O servidor de desenvolvimento recarrega o código Python a cada request, se necessário. Você não precisa reiniciá-lo para que mudanças no código tenham efeito. Quando iniciar o servidor, a cada vez que você mudar o código Python enquanto ele estiver rodando, o servidor validará todos os seus models instalados. (Veja o comando ``validate`` abaixo.) Se o validador encontrar erros, ele os imprimirá na saída padrão, mas não parará o servidor. Você pode rodar quantos servidores você quiser, desde que estejam em portas separadas. É só executar ``django-admin.py runserver`` mais de uma vez. Note que o endereço IP padrão, 127.0.0.1, não é acessível para outros computadores de sua rede. Para ter seu servidor de desenvolvimento visível por outros na rede, use seu próprio endereço IP (e.g. ``192.168.2.1``) ou ``0.0.0.0``. .. django-admin-option:: --adminmedia Use a opção ``--adminmedia`` para dizer ao Django onde encontrar os vários arquivos CSS e JavaScript da interface de administração do Django. Normalmente, o servidor de desenvolvimento serve estes arquivos da árvore de código do Django magicamente, mas você pode querer usar isso, caso tenha feito quaisquer mudanças nos arquivos para seu próprio site. Exemplo de uso:: django-admin.py runserver --adminmedia=/tmp/new-admin-style/ .. django-admin-option:: --noreload Use a opção ``--noreload`` para desabilitar o uso do auto-reloader. Isso significa que quaisquer mudanças no código Python, feitas enquanto o servidor estiver rodando, não terá efeito se o módulo em particular já foi carregado na memória. Exemplo de uso:: django-admin.py runserver --noreload Exemplos de uso com diferentes portas e endereços ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Porta 8000 no endereço IP 127.0.0.1:: django-admin.py runserver Porta 8000 no endereço IP 1.2.3.4:: django-admin.py runserver 1.2.3.4:8000 Porta 7000 no endereço IP 127.0.0.1:: django-admin.py runserver 7000 Porta 7000 no endereço IP 1.2.3.4:: django-admin.py runserver 1.2.3.4:7000 Servindo arquivos estáticos com o servidor de desenvolvimento ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Por padrão, o servidor de desenvolvimento não serve quaisquer arquivos estáticos para o site (como arquivos CSS, imagens, coisas sob o ``MEDIA_URL``, etc). Se você deseja configurar o Django para servir arquivos de mídia estáticos, leia :ref:`howto-static-files`. shell ----- Começa o interpretador Python interativo. O Django usará o IPython_, se ele estiver instalado. Se você tem o IPython instalado e quer forçar o uso do interpretador Python "plano", use a opção ``--plain``, desta forma:: django-admin.py shell --plain .. _IPython: http://ipython.scipy.org/ sql ------------------------- Imprime a consulta SQL CREATE TABLE para as *app name* fornecidas. sqlall ---------------------------- Imprime as consultas SQL CREATE TABLE e initial-data, para as *app name* fornecidas. Leia a descrição de ``sqlcustom`` para uma explicação de como especificar dados iniciais. sqlclear ------------------------------ Imprime a consulta SQL DROP TABLE para as app name fornecidas. sqlcustom ------------------------------- Imprime a consulta SQL para as app name fornecidas. Para cada model em cada app especificada, este comando procura pelo arquivo ``/sql/.sql``, onde ```` é o nome dado da aplicação ```` é o nome do model em minúsculo. Por exemplo, se você tem uma app ``news`` que inclui um model ``Story``, o ``sqlcustom`` tentará ler o arquivo ``news/sql/story.sql`` e irá adicionar à saída deste comando. Cada arquivo SQL, se fornecido, é esperado que contenha SQL válido. Os arquivos SQL são entubados diretamente dentro do banco de dados depois que todos as consultas de criação de tabelas foram executadas. Use este hook SQL para fazer quaisquer modificações em tabelas, ou inserir qualquer função SQL dentro do banco de dados. Note que a ordem em que os arquivos SQL são processados é indefinida. sqlflush -------- Imprime a instrução SQL que será executada pelo comando `flush`_. sqlindexes -------------------------------- Imprime a instrução SQL CREATE INDEX SQL para as *app name* fornecidas. sqlreset ------------------------------ Imprime o SQL DROP TABLE, seguido do SQL CREATE TABLE, para as *app name* fornecidas. sqlsequencereset -------------------------------------- Imprime as instruções SQL para *resetar* as seqüencias das *app name* fornecidas. Seqüências são índices usados por alguns bancos de dados para rastrear o próximo número disponível automaticamente, em campos incrementais. Use este comando para gerar SQL que consertará casos em que uma sequência está fora de sincronia com seus dados de campos automaticamente incrementados. startapp ------------------ Cria uma estrutura de diretório de aplicação Django com o nome fornecido, no diretório corrente. startproject -------------------------- Cria uma estrutura de diretório de projeto Django com o nome fornecido, no diretório corrente. Este comando é desabilitado quando a opção ``--settings`` para o ``django-admin.py`` é usado, ou quando a variável de ambiente ``DJANGO_SETTINGS_MODULE`` estiver definida. Para rehabilitá-lo nestas situações, deve-se omitir a opção ``--settings`` ou anular o ``DJANGO_SETTINGS_MODULE``. syncdb ------ Cria as tabelas do banco de dados para todas as aplicações em ``INSTALLED_APPS`` cujo as tabelas ainda não foram criadas. Use este comando quando você tiver adicionado novas aplicações ao seu projeto e quer instalá-las no banco de dados. Isso inclui quaisquer aplicações entregues com o Django, que podem estar no ``INSTALLED_APPS`` por padrão. Quando você iniciar um novo projeto, execute este comando para instalar as aplicações padrão. .. admonition:: syncdb não altera tabelas existentes ``syncdb`` somente criará tabelas para os models que não foram instalados ainda. Ele *nunca* emite uma consulta ``ALTER TABLE`` para combinar mudanças feitas na classe do model depois da instalação. Mudanças de models e esquemas de banco de dados normalmente envolvem alguma forma de ambiguidade e, em alguns casos, o Django não adivinhará quais as mudanças corretas fazer. Há um risco de que dados críticos poderiam ser perdidos no processo. Se você tem feito mudanças em models e deseja alterar as tabelas do banco de dados, use o comando ``sql`` para mostrar a nova estrutura do SQL e compare-a com o seu esquema de tabelas atual, para fazer as mudanças. Se você estiver instalando a aplicação ``django.contrib.auth``, o ``syncdb`` dará a você a opção de criar um superusuário imediatamente. O ``syncdb`` também procurará por, e instalará, qualquer fixture chamada ``initial_data`` com uma extenção apropriada (e.g. ``json`` ou ``xml``). Veja a documentação para ``loaddata`` para detalhes sobre a especificação de arquivos de dados de fixture. --verbosity ~~~~~~~~~~~ Use ``--verbosity`` para especificar o quanto de notificações e informações de debug o ``django-admin.py`` deverá imprimir no console. * ``0`` significa nenhuma saída. * ``1`` significa saída normal (padrão). * ``2`` significa saída prolixa. Exemplo de uso:: django-admin.py syncdb --verbosity=2 --noinput ~~~~~~~~~ Use a opção ``--noinput`` para suprimir todo prompt ao usuário, como mensagens de confirmação "Você tem certeza?". Isso é útil se o ``django-admin.py`` for executado de forma autônoma, por um script. test ---- Executa os testes para todos os models instalados. Veja :ref:`topics-testing` para mais informações. --noinput ~~~~~~~~~ Use a opção ``--noinput`` para suprimir todo prompt ao usuário, como mensagens de confirmação "Você tem certeza?". Isso é útil se o ``django-admin.py`` for executado de forma autônoma, por um script. --verbosity ~~~~~~~~~~~ Use ``--verbosity`` para especificar o quanto de notificações e informações de debug o ``django-admin.py`` deverá imprimir no console. * ``0`` significa nenhuma saída. * ``1`` significa saída normal (padrão). * ``2`` significa saída prolixa. Exemplo de uso:: django-admin.py test --verbosity=2 testserver -------------------------------- .. versionadded:: 1.0 Executa um servidor de desenvolvimento Django (como no ``runserver``) usando dados de fixture(s) fornecida(s). Por exemplo, este comando:: django-admin.py testserver mydata.json ...executaria os seguintes passos: 1. Cria um banco de dados de teste, como descrito em :ref:`topics-testing`. 2. Popula o banco de dados de teste com os dados das fixtures. (Para saber mais sobre fixtures, veja a documentação para ``loaddata`` acima.) 3. Executa o servidor de desenvolvimento do Django (como no ``runserver``), apontando para este novo banco de dados criado, ao invés do seu banco de dados de produção. Isso é útil de diversas formas: * Quando você estiver escrevendo :ref:`unit tests ` de como seus views agem com certos dados de fixture, você pode usar ``testserver`` para interagir com os views no navegador Web, manualmente. * Vamos dizer que você está desenvolvendo sua aplicação Django e tem uma cópia antiga do banco de dados com a qual você gostaria de interagir. Você pode extrair seu banco de dados para uma fixture (usando o comando ``dumpdata``, explicado acima), e então usar ``testserver`` para rodar sua aplicação Web com estes dados. Com este arranjo, você tem a flexibilidade de interagir com seus dados de qualquer forma, sabendo que qualquer dado alterado está tendo efeito somente no seu banco de dados de teste. Note que este servidor *não* detecta automaticamente mudanças no seu código Python (como ``runserver`` faz). Ele, no entanto, detecta mudanças nos seus templates. --addrport [número da porta ou ipaddr:port] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Use ``--addrport`` para especificar uma porta diferente, ou endereço de IP e porta, no padrão 127.0.0.1:8000. Este valor segue exatamente o mesmo formato e exerce a mesma função do argumento para o subcomando ``runserver``. Exemplos: Para rodar o servidor de test na porta 7000 com o ``fixture1`` e ``fixture2``:: django-admin.py testserver --addrport 7000 fixture1 fixture2 django-admin.py testserver fixture1 fixture2 --addrport 7000 (As regras acima são equivalente. Nós incluímos ambas para demonstrar que não importa se as opções vem antes ou depois dos argumentos de fixture.) Para rodar sobre 1.2.3.4:7000 um fixture ``test``:: django-admin.py testserver --addrport 1.2.3.4:7000 test --verbosity ~~~~~~~~~~~ Use ``--verbosity`` para especificar o quanto de notificações e informações de debug o ``django-admin.py`` deverá imprimir no console. * ``0`` significa nenhuma saída. * ``1`` significa saída normal (padrão). * ``2`` significa saída prolixa. Exemplo de uso:: django-admin.py testserver --verbosity=2 validate -------- Valida todos os models instalados (de acordo com a configuração ``INSTALLED_APPS``) e imprime erros de validação na saída padrão. Opções padrão ============= Embora alguns subcomandos possam permitir suas próprias opções personalizadas, todo subcomando permite as seguintes opções: --pythonpath ------------ Exemplo de uso:: django-admin.py syncdb --pythonpath='/home/djangoprojects/myproject' Adiciona o caminho do sistema de arquivos para o `caminho de busca`_ do Python. Se este não for fornecido, o ``django-admin.py`` usará a variável de ambiente ``PYTHONPATH``. Note que esta opção é desnecessária para o ``manage.py``, pois ele se preocupa em definir o caminho do Python por você. .. _caminho de busca: http://diveintopython.org/getting_to_know_python/everything_is_an_object.html --settings ---------- Exemplo de uso:: django-admin.py syncdb --settings=mysite.settings Explicitamente especifica o módulo settings a se usar. O módulo settings deve estar na sintaxe de pacotes Python, e.g. ``mysite.settings``. Se este não for fornecido, ``django-admin.py`` usará a variável de ambiente ``DJANGO_SETTINGS_MODULE``. Note que esta opção é desnecessária no ``manage.py``, pois ele usa o ``settings.py`` do projeto atual por padrão. --traceback ----------- Exemplo de uso:: django-admin.py syncdb --traceback Por padrão, ``django-admin.py`` mostrará uma mensagem de erro simples sempre que um erro ocorrer. Se você especificar ``--traceback``, o ``django-admin.py`` mostrará uma pilha completa sempre que uma exceção for lançada. Sutilezas extra =============== Sintaxe colorida ---------------- Os comandos ``django-admin.py`` / ``manage.py`` que mostram SQL na saída padrão usarão uma saída de código colorida se seu terminal suporta saída ANSI-colored. Ele não usa os códigos de cor se você estiver tunelando comandos para um outro programa. Bash completion --------------- Se você usa o terminal Bash, considere instalar o script de Bash completion do Django, que reside em ``extras/django_bash_completion`` na distribuição do Django. Ele habilita o auto completar com tab dos comandos ``django-admin.py`` e ``manage.py``, então você pode, por instância... * Escrever ``django-admin.py``. * Precionar [TAB] para ver todas as opções disponíveis. * Escrever ``sql``, então [TAB], para ver todas as opções disponíveis cujo nome começa com ``sql``. Veja :ref:`howto-custom-management-commands` para saber como adicionar ações personalizadas.