Sendo mais ágil com o appadmin

No artigo "Quem alterou um registro" eu mostrei como o web2py agiliza e padroniza a criação e controle de dados das tabelas automaticamente.

Mas quando estamos testando o aplicativo e usando o appadmin, precisamos de agilidade para incluir e alterar registros no bd.

Daí, para passar a validação de quem incluiu um registro, faça conforme abaixo:

""" Alterando o auth.signature para permitir
inserts anônimos pelo appadmin. """

db.minha_tabela.created_by.required = False
db.minha_tabela.created_by.requires = IS_EMPTY_OR( \
    db.carro.created_by.requires)

db.minha_tabela.modified_by.required = False
db.minha_tabela.modified_by.requires = IS_EMPTY_OR( \
    db.carro.modified_by.requires)

Assim, você não vai precisar escolher um autor para o registro.

Observações:

1. Coloque o trecho de código mostrado, abaixo do db.define_table() da tabela que você está testando.
2. Só use esse recurso em ambiente de desenvolvimento porquê você terá registros sem a identificação de quem os incluiu/alterou.

Fica a dica.

Quem alterou um registro

Detalhes fazem a diferença, certo? O web2py se preocupa com eles para dar produtividade ao desenvolvedor.

Uma boa ideia é o auth.signature

Vamos a um exemplo:

db.define_table('cadastro',
  Field('nome', 'string', length=100),
  Field('telefone', 'string', length=20),
  auth.signature)

Esse comando vai criar uma tabela chamada cadastro com os campos id (criado automaticamente), nome e telefone, além de: created_on, created_by, modified_on e modified_by.

Isso faz com que possamos saber quando um registro foi incluído (created_on) ou alterado (modified_on).

O auth.signature funciona automaticamente integrado ao sistema de autenticação do web2py. Portanto, se um usuário logado incluir ou alterar o registro, o código de usuário dele ficará registrado nos campos created_by e modified_by.

Fica aí a dica.

Fixtures no Web2py

Uma das coisas boas dos frameworks modernos é trabalhar com fixtures.

Se você ainda não sabe, fixtures são a massa de dados inicial do seu banco de dados. Aqueles registros que você inclui só pra testar suas consultas, lembra? Pois é; são fixtures. E dá um trabalho danado incluir novamente toda vez que você precisa mudar alguma coisa no seu banco de dados, né? As fixtures estão aí pra ajudar exatamente nisso.

O esquema é o seguinte: você define um conjunto de dados inicial. Daí, toda vez que as tabelas são criadas, os dados são inseridos automaticamente, pra você não ter que popular tudo na mão novamente.

Isso te dá liberdade (e segurança) de apagar tudo e recomeçar sem sujeira nas tabelas. A qualquer momento você pode esvaziar ou recriar tudo. Sua massa de teste estará lá novamente. É como se fosse um "quick restore" dos seus dados.

Posso dizer que é uma mão na roda, mas é preciso tomar alguns cuidados para não se perder.

Eu usei fixtures pela primeira vez no Django e demorou um pouco até cair a ficha sobre como isso funciona no web2py. De tão fácil que é, às vezes a gente nem percebe.

Você pode trabalhar com fixtures no Web2py de 3 formas:
a) Incluindo as linhas via script que é executado automaticamente;
b) Importando de um arquivo CSV;
c) Mesclando as duas formas anteriores.

Os scripts do diretório my_app/models são executados em ordem alfabética sempre que sua aplicação é requisitada. Ou seja, a cada request. Portanto, ali é um bom lugar para colocar scripts que fazem alguma configuração ou preparação para sua aplicação rodar. Bem, as fixtures fazem exatamente isso, certo? Elas preparam a massa de dados de sua aplicação. Portanto, podemos iniciar as fixtures chamando-as a partir do script my_app/models/z_fixtures.py, por exemplo.

Nesse script, você pode incluir os dados iniciais se suas tabelas estiverem vazias, fazendo o seguinte teste:

if db(db.produtos.id>0).count() == 0:
    db.produtos.insert(codigo=1234, nome='martelo')
    db.produtos.insert(codigo=1235, nome='parafuso')
    db.commit()

Fazendo isso para todas as tabelas, você terá seus dados recarregados sempre que esvaziá-las.
A vantagem desse método é que você tem total domínio sobre a forma de inclusão dos dados. A desvantagem é que escreve muito código.

A outra forma de trabalhar com fixtures, é usando o appadmin (my_app/appadmin) para inserir os dados e usar a opção "exportar para csv", que tem na view de listagem dos dados.

A vantagem desse método é que você garante a inclusão de dados que passaram pelos validadores definidos e aproveita a exportação para csv que já vem com o Web2py.
Uma desvantagem é que você vai ter que importar os dados na mão sempre que suas tabelas forem zeradas. A outra é que, dependendo da mexida nas tabelas, suas fixtures podem não carregar por diferença de layout.

Mas, será que existe uma maneira de aproveitar e unir as duas formas abordadas? Sim, claro. O Web2py é flexível e praticamente tudo que é possível fazer pelo appadmin, também é possível fazer via programação.

Então, sugiro você usar o appadmin para inserir os dados, exportá-los para csv pelo próprio appadmin e o método db.minha_tabela.import_from_csv_file() no script my_app/models/z_fixtures.py para importar os dados, se a tabela estiver vazia.

Aproveite e veja os métodos para importar/exportar um banco de dados inteiro. Isso pode te ajudar bastante.

Experimente. Use fixtures e você verá como sua vida fica mais fácil e produtiva.