.. META INFORMAÇÕES DA TRADUÇÃO .. Tradução: Denis Costa .. Revisão: ====================================== Provendo dados inicias para os modelos ====================================== As vezes é útil pré popular seu banco de dados com dados pré-definidos quando você está iniciando sua aplicação pela primeira vez. Existem algumas formas do Django criar esse dados automaticamente: você pode prover `dados iniciais usando fixtures`_ , ou pode prover `dados inicias em SQL`_ . De maneira geral, usar uma fixture é um métodos simples desde que o banco de dados seja agnóstico, mas dados inicias com SQL podem ser um pouco mais flexíveis. .. _dados inicias em SQL: `provendo-dados-inicias-em-sql`_ .. _dados iniciais usando fixtures: `dados-iniciais-usando-fixtures`_ .. _dados-iniciais-usando-fixtures: Provendo dados iniciais com fixtures ==================================== Uma fixture é uma coleção de dados que o Django sabe como importar para um banco de dados. O jeito mais simples de criar uma fixture, caso você já tenha algum dado, é usar o comando :djadmin:`manage.py dumpdata `. Ou, você pode escrever fixtures na mão; fixtures podem ser escritas em XML, YAML ou documento JSON. A :doc:`documentação de serialização ` tem mais detalhes sobre cada :ref:`formatos de serialização `. Como exemplo, aqui está como uma fixture, de um model ``Person`` simples, parece em JSON: .. code-block:: js [ { "model": "myapp.person", "pk": 1, "fields": { "first_name": "John", "last_name": "Lennon" } }, { "model": "myapp.person", "pk": 2, "fields": { "first_name": "Paul", "last_name": "McCartney" } } ] E aqui está a mesma fixture em YAML: .. code-block:: none - model: myapp.person pk: 1 fields: first_name: John last_name: Lennon - model: myapp.person pk: 2 fields: first_name: Paul last_name: McCartney Você deve armazenar esses dados em um diretório chamado ``fixtures`` dentro da sua aplicação. Carregar dados é fácil: apenas digite :djadmin:`manage.py loaddata \ `, onde ```` é o nome do arquivo de fixture que você criou. Cada vez que você executa :djadmin:`loaddata`, os dados serão lidos apartir da fixture e recarregados para o banco de dados. Note que isso significa que se você mudar uma das linhas criadas pelo fixture e depois executar :djadmin:`loaddata` novamente, você perderá qualquer mudança que tenha você feito. Carregando automaticamente dados iniciais da fixture ---------------------------------------------------- Se você criar uma fixture chamada ``initial_data.[xml/yaml/json]``, essa fixture será carregada toda vez que você executar :djadmin:`syncdb`. Isso é extremamente conveniente, mas você deve ser cuidadoso: Lembre-se que os dados serão atualizados *toda vez* que você executar :djadmin:`syncdb`. Então não use ``initial_data`` para dados que você possa querer editar. Onde o Django encontra os arquivos fixture ------------------------------------------ Por padrão, O Django procura nos diretórios ``fixtures`` dentro de cada aplicação por fixtures. Você pode configurar o :setting:`FIXTURE_DIRS` informando uma lista de diretórios adicionais onde o Django deve procurar. Quando estiver executando :djadmin:`manage.py loaddata `, você pode também especificar um caminho absoluto até o arquivo fixture, o que evita a procura normal nos diretórios. .. seealso:: Fixtures are also used by the :ref:`testing framework ` to help set up a consistent test environment. .. _provendo-dados-inicias-em-sql: Provendo dados inicias em SQL ============================= Django provê um mecanismo que para passar para o banco de dados um SQL qualquer que é executado logo após o CREATE TABLE quando você executa :djadmin:`syncdb`. Você pode usar isso para popular com registro pré definidos, ou você poderia criar funções, views, triggers SQL e etc. O mecanismo é simples: O Django procura pór um arquivo chamado ``sql/.sql``, no diretório da sua aplicação, onde ```` é o nome do modelo em minúsculo. Então, se você tiver um model ``Person`` na sua aplicação chamada ``myapp``, você pode adicionar um SQL qualquer ao arquivo ``sql/person.sql`` dentro do diretório ``myapp``. Aqui tem exemplo do que o arquivo pode conter: .. code-block:: sql INSERT INTO myapp_person (first_name, last_name) VALUES ('John', 'Lennon'); INSERT INTO myapp_person (first_name, last_name) VALUES ('Paul', 'McCartney'); Cada arquivo SQL, caso ele exista, é esperado que contenha comando SQL válidos que irão inserir os dados desejados (e.g., comandos ``INSERT`` devidamente formatados e separados por ponto e virgula). Os arquivos SQL são lidos pelos comandos :djadmin:`sqlcustom`, :djadmin:`sqlreset`, :djadmin:`sqlall` e :djadmin:`reset` no :doc:`manage.py `. Veja a documentação :doc:`manage.py documentation ` para mais informações. Note que se você tem multiplos arquivos SQL com dados, não existe garantia da ordem na qual os arquivos serão executados. A única cois que você pode assumir é que, no momento que seus arquivos customizados forem executados, todas as tabelas do banco de dados serão criadas. .. admonition:: Testando dados iniciais em SQL Essa técnica *não pode* ser usada para prover dados inicias com propositos de teste. O framework de teste do Django limpa o conteúdo do banco de dados de teste a cada teste; como resultado, nenhum dado adicionado usando o mecanismo de SQL customizadas será perdido. Se você precisa de dados para um caso de teste, você deve adiciona-los usando uma :ref:`fixture de teste `, ou programaticamente adiciona-los durante o ``setUp()`` do seu caso de teste. Dados SQL para um backend de banco de dados específico ------------------------------------------------------ Existe também um mecanismo para dados em SQL de um backend específico. Por exemplo, você pode separar arquivos com dados iniciais para PostgreSQL e SQLite. Para cada aplicação, O Django procura por um arquivo chamado ``/sql/..sql``, onde ```` é o diretório da sua aplicação, ```` é o nome do model em minúsculos e ```` é o última parte do nome do módulo configurado no :setting:`ENGINE` no seu arquivo settings (e.g., se você tem um :setting:`ENGINE` de banco de dados com o valor ``django.db.backends.sqlite3``, o Django vai procurar por ``/sql/.sqlite3.sql``). Dados SQL para um backend específico são executados antes do dados não específicos. Por exemplo, se sua aplicação contém arquivos ``sql/person.sql`` e ``sql/person.sqlite3.sql`` e você está instalando a aplicação no SQLite, O Django vai executar o conteúdo de ``sql/person.sqlite.sql`` primeiro, e então ``sql/person.sql``.