Provendo dados inicias para models

As vezes é útil povoar seu banco de dados com dados no momento da instalação de uma aplicação. Aqui há algumas formas de se fazer o Django criar estes dados automaticamente: você pode prover dados iniciais usando fixtures ou você pode prover dados iniciais em SQL.

Geralmente, usar um fixture é um método mais limpo desde que o banco de dados seja agnóstico, mas dados iniciais em SQL podem ser um pouco mais flexiveis.

Provendo dados iniciais com fixtures

Uma fixture é uma coleção de dados que o Django sabe com importar para dentro de um banco de dados. A forma mais simples de se criar uma fixture, se você já tem alguns dados, é usando o comando manage.py dumpdata. Ou, você pode escrever a mão; as fixtures podem ser escritas em XML, YAML, ou JSON. A documentação de serialização tem mais detalhes sobre cada um destes formatos de serialização suportados.

Como exemplo, aqui é mostrado uma fixture para um model simples Person, no formato JSON:

[
  {
    "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 tem a mesma fixture como YAML:

- 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ê armazenará estes dados em um diretório fixtures dentro de sua aplicação.

Carregar os dados é fácil: é só chamar manage.py loaddata fixturename, onde fixturename é o nome do arquivo fixture que você criou. Toda vez que você executar loaddata os dados serão lidos da fixture e recarregados no banco de dados. Note que isto significa que se você mudar algum dado criado por uma fixture e rodar loaddata novamente, ele irá sobrescrever a mudanças feitas.

Carregando automaticamente os dados iniciais de fixtures

Se você criar uma fixture chamada initial_data.[xml/yaml/json], essas fixtures serão carregadas sempre que você rodar syncdb. Isto é extremamente conveniente, mas seja cuidadoso: lembre-se qeu os dados serão atualizado toda vez que voce executar syncdb. Então não use initial_data para dados que você deseja editar.

See also

As fixtures são usadas também pelo framework de testes para ajudar a montar um ambiente consistente de testes.

Provendo dados iniciais em SQL

O Django provê um hook para passar SQL arbitrário para o banco de dados, que é executado somente depois de uma consulta CREATE TABLE, no momento em que você roda um syncdb. Você pode usar este hook para popular com dados padrões, ou também criar funções SQL, view, triggers, etc.

O hook é simples: o Django simplesmente procura por um arquivo chamado sql/<modelname>.sql, no diretório da aplicação, onde <modelname> é o nome do model em minúsculo.

Então, se você tem um model Person em uma aplicação chamada myapp, você poderia adicionar SQL arbitrário num arquivo sql/person.sql dentro do diretório myapp. Aqui tem um exemplo do que o arquivo pode conter:

INSERT INTO myapp_person (first_name, last_name) VALUES ('John', 'Lennon');
INSERT INTO myapp_person (first_name, last_name) VALUES ('Paul', 'McCartney');

Para cada arquivo SQL, se fornecido, é esperado que contenha consultas SQL válidas que irão inserir os dados desejados (e.g., consultas INSERT apropriadamente formadas, separadas por ponto-e-vírgula);

Os arquivos SQL são lidos pelos comandos sqlcustom, sqlreset, sqlall e reset no manage.py. Consulte a documentação do manage.py para mais informações.

Note que se você tem múltiplos arquivos de dados SQL, não há garantias da ordem em que eles serão executados. A única coisa que pode ser assumida, é que no momento em que todos forem executados, o banco de dados já estará com todas as suas tabelas criadas.

Dados SQL para um backend específico de banco de dados

Há também um kook para backend específico de dados SQL. Por exemplo, você pode ter separados arquivos com dados iniciais para PostgreSQL e MySQL. Para cada applicação, o Django procura por um arquivo chamado <appname>/sql/<modelname>.<backend>.sql, onde <appname> é o diretório de sua aplicação, <modelname> é o nome do model em minúsculo e <backend> é o valor de DATABASE_ENGINE no seu arquivo settings (e.g., postgresql, mysql).

O backend específico de dados SQL é executado antes do backend não-específico de dados SQL. Por exemplo, se sua aplicação contém os arquivos sql/person.sql e sql/person.postgresql.sql e você está instalando a aplicação sobre o PostgreSQL, o Django irá executar o conteúdo do sql/person.postgresql.sql primeiro, e então sql/person.sql.

« previous | up | next »