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.

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 manage.py dumpdata. Ou, você pode escrever fixtures na mão; fixtures podem ser escritas em XML, YAML ou documento JSON. A documentação de serialização tem mais detalhes sobre cada formatos de serialização.

Como exemplo, aqui está como uma fixture, de um model Person simples, parece em 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 está a mesma fixture em 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ê deve armazenar esses dados em um diretório chamado fixtures dentro da sua aplicação.

Carregar dados é fácil: apenas digite manage.py loaddata <nomedafixture>, onde <nomedafixture> é o nome do arquivo de fixture que você criou. Cada vez que você executa 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 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 syncdb. Isso é extremamente conveniente, mas você deve ser cuidadoso: Lembre-se que os dados serão atualizados toda vez que você executar 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 FIXTURE_DIRS informando uma lista de diretórios adicionais onde o Django deve procurar.

Quando estiver executando manage.py loaddata, você pode também especificar um caminho absoluto até o arquivo fixture, o que evita a procura normal nos diretórios.

See also

Fixtures are also used by the testing framework to help set up a consistent test environment.

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 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/<modelname>.sql, no diretório da sua aplicação, onde <modelname> é 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:

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 sqlcustom, sqlreset, sqlall e reset no manage.py. Veja a documentação 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.

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 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 <nomedaaplicacao>/sql/<nomedomodel>.<backend>.sql, onde <nomedaaplicacao> é o diretório da sua aplicação, <nomedomodel> é o nome do model em minúsculos e <backend> é o última parte do nome do módulo configurado no ENGINE no seu arquivo settings (e.g., se você tem um ENGINE de banco de dados com o valor django.db.backends.sqlite3, o Django vai procurar por <appname>/sql/<modelname>.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.

« previous | up | next »