Artigos

2009-08-18T14:59:59Z

Outros

Tutorial de agregação do Django

2009-08-18T14:59:09Z

Tutorial de agregação do Django

Originalmente publicado em http://uswaretech.com/blog/2009/08/django-aggregation-tutorial/ , tradução de Walter Cruz

Um das funcionalidades mais aguardados do Django 1.1 era a agregação. Como sempre, o Django vem com uma documentação muito completa sobre isso. Aqui, eu tentei colocar isso de uma forma mais semelhante a um howto.

Pule para os howtos ou obtenha o código no Github.

Para fazer essas operações o Django adicionou dois métodos aos querysets:

aggregate
annotate

Quando você tem um queryset você pode fazer duas operações nele,

Operar sobre o conjunto de linhas para obter um único valor dele. (Como a soma de todos os salários em um conjunto de linhas)
Operar sobre o conjunto de linhas para obter um valor de cada linha no conjunto de linhas por meio de alguma tabela relacionada.

Deve ser reparado que a opção 1 irá criar uma linha do conjunto de dados, enquanto a opção 2 não irá mudar o número de linhas no conjunto de dados. Se você gosta de analogias, pode pensar na opção 1 como um reduce e na opção 2 como um map.

Em termos de sql, agregação é uma operação (SUM, AVG, MIN, MAX) sem um group by, enquanto um annotate é uma operação com um group by em rowset_table.id. (A menos que explicitamente sobrescrito).

Ok, falei demais, vamos ver isso funcionando. Aqui está um models.py fictício representando um sistema de departamento pessoal. Usaremos isso para ver como a agregação resolve nossos problemas comuns.

from django.db import models

class Department(models.Model):
   dept_name = models.CharField(max_length = 100)
   established_on = models.DateField()

   def __unicode__(self):
       return self.dept_name

class Level(models.Model):
   level_name = models.CharField(max_length = 100)
   pay_min = models.PositiveIntegerField()
   pay_max = models.PositiveIntegerField()

   def __unicode__(self):
       return self.level_name

class Employee(models.Model):
   emp_name = models.CharField(max_length = 100)
   department = models.ForeignKey(Department)
   level = models.ForeignKey(Level)
   reports_to = models.ForeignKey('self', null=True, blank=True)

   pay = models.PositiveIntegerField()
   joined_on = models.DateField()

class Leave(models.Model):
   employee = models.ForeignKey(Employee)
   leave_day = models.DateField()


"""
#Populate DB, so we can do some meaningful queries.
#Create Dept, Levels manually.
#Get the names file from http://dl.getdropbox.com/u/271935/djaggregations/names.pickle
#Or the whole sqlite database from http://dl.getdropbox.com/u/271935/djaggregations/bata.db
import random
from datetime import timedelta, date
import pickle
names = pickle.load(file('/home/shabda/names.pickle'))
for i in range(1000):
    emp = Employee()
           emp.name = random.choice(names)
           emp.department = random.choice(list(Department.objects.all()))
           emp.level = random.choice(Level.objects.all())
           try: emp.reports_to = random.choice(list(Employee.objects.filter(department=emp.department)))
           except:pass
           emp.pay = random.randint(emp.level.pay_min, emp.level.pay_max)
           emp.joined_on = emp.department.established_on + timedelta(days = random.randint(0, 200))
           emp.save()
"""

"""
employees = list(Employees.objects.all())
for i in range(100):
   employee = random.choice(employees)
   leave = Leave(employee = employee)
   leave.leave_day = date.today() - timedelta(days = random.randint(0, 365))
   leave.save()
"""

Encontrar o número total de empregados.

Em sql você poderia fazer algo como,

select count(id) from hrms_employee

Que se torna,

Employee.objects.all().aggregate(total=Count('id'))

De fato, fazendo um connection.queries.pop() mostra exaramente essa consulta.

SELECT COUNT("hrms_employee"."id") AS "total" FROM "hrms_employee"

Mas espera, já temos um método padrão para isso, o Employee.objects.all().count(), então vamos tentar outra coisa.

Encontrar o pagamento total dos empregados

O CEO quer saber qual é o total gasto nos salários, isso também converte o queryset em um único valor, então vamos usad o .aggregate aqui.

Employee.objects.all().aggregate(total_payment=Sum('pay'))

Lhe informa a quantidade total que você paga a seus empregados.

Encontrar o número total de empregados, por departamento.

Aqui nós queremos um valor por linha no queryset, então precisamos usar um agregado aqui. Também, queremos um agregado por departamento, então precisamos anotar o queryset do Department.

Department.objects.all().annotate(Count('employee'))

Se você está apenas interessando no nome do departamento e no total de empregados nele, você pode fazer, Department.objects.values('dept_name').annotate(Count('employee'))

O sql é

SELECT "hrms_department"."dept_name", COUNT("hrms_employee"."id") AS "employee__count" FROM "hrms_department" LEFT OUTER JOIN "hrms_employee" ON ("hrms_department"."id" = "hrms_employee"."department_id") GROUP BY "hrms_department"."dept_name"

Encontrar o número total de empregados, por meio de um departamnento específico.

Aqui você pode usar tanto o .annotate como o .aggregate

Department.objects.filter(dept_name='Sales').values('dept_name').annotate(Count('employee')) Department.objects.filter(dept_name='Sales').aggregate(Count('employee'))

Se você olhar os SQLs, verá que o .annotate fez um group by, enquanto o .aggregate não, mas como só havia uma linha, o group by não teve efeito.

Encontrar o número total de empregados e seus níveis, por departamento

Dessa vez, queremos anotar ambos o modelo do Department ou do Level, já que precisamos agrupar tanto por um quanto pelo outro. Então vamos anotar no Employee

Employee.objects.values('department__dept_name', 'level__level_name').annotate(Count('id'))

Isso gera o sql,

SELECT "hrms_department"."dept_name", "hrms_level"."level_name", COUNT("hrms_employee"."id") AS "id__count" FROM "hrms_employee" INNER JOIN "hrms_department" ON ("hrms_employee"."department_id" = "hrms_department"."id") INNER JOIN "hrms_level" ON ("hrms_employee"."level_id" = "hrms_level"."id") GROUP BY "hrms_department"."dept_name", "hrms_level"."level_name

Que combinação de Employee e Deparments emprega a maior parte das pessoas

Podemos ordenar pelos campos anotados, de forma que a última consulta fique assim,

Employee.objects.values('department__dept_name', 'level__level_name').annotate(employee_count = Count('id')).order_by('-employee_count')[:1]

Qual é o nome de empregado mais comum.

Podemos agrupar por emp_name, então emp_name é adicionado aos valores. Após isso nós ordenamos pelo campo anotado e objetos o primeiro elemento, para obter o nome mais comum.

Employee.objects.values('emp_name').annotate(name_count=Count('id')).order_by('-name_count')[:1]

Essa foi uma visão geral de como as anotações funcionam no django. Isso remove uma grabde parte de consultas para as quais você tinha de escrever sql na unha antigamente.

Um Hello World para o Ruby em Ragel 6.0

2009-07-28T23:08:26Z

Um Hello World para o Ruby em Ragel 6.0

Tradução de: http://www.devchix.com/2008/01/13/a-hello-world-for-ruby-on-ragel-60/

Essa é uma versão atualizada desse tutorial. Essa versão atualizada é compatível com Ruby 1.8 e Ruby 1.9, e Ragel 6.0.

No fim desse post, você será capaz de transformar uma simples string “h” em uma string muito mais interessante e maior, “hello world!”, usando a magia do Ragel, tudo com o conforto de Ruby. Ragel é um poderoso compilador de máquinas de estados e gerador de parser, que é o coração de softwares como Mongrel e Hpricot. É capaz de gerar código C, C++, Objective-C, D, Java ou código Ruby.

Ragel tem documentação excelente fornecida pelo autor. Meu alvo aqui é somente fornecer algum contexto para que a documentação faça ainda mais sentido quando você a ler, e fornecer um exemplo que você pode modificar conforme explora a funcionalidade do Ragel. Se você quer ir direto ao ponto, o exemplo completo está aqui.

O primeiro passo, é claro, a instalação do Ragel. A home page do Ragel tem uma seção de downloads que lista versões para várias plataformas. Se você já tem o Ragel instalado, verifique se a versão é 6.0 ou maior. Você pode também compilar e instalar o Ragel pelo fonte. Mesmo se você não quer instalar a partir do código fonte, é interessante ter uma cópia dele, pois ela contém alguns exemplos que você pode testar. O repositório subversion do ragel está localizado aqui:

svn://mambo.cs.queensu.ca/ragel/trunk/

Como de praxe, o diretório test/ é seu amigo, veja também o diretório examples/. Conforme essa thread, tente procurar por “LANG: ruby”.

Ao escrever código Ragel, você pode criar um arquivo com uma extensão .rl. O arquivo .rl é escrito na linguagen "hospedeira", nesse caso, Ruby, e a especificação da máquina de estados Ragel é embutida dentro do código Ruby usando delimitadores especiais. Não é obrigatório especificar uma máquina de estados, então um arquivo .rl perfeitamente válido pode ser:

puts "hello world"

Não se preocupe, eu farei um Hello World melhor que esse, mas esse é um bom lugar pra começar. Para converter esse arquivo .rl em um executável .rb file, use o comando "ragel" com o argumento -R para indicar que você quer código Ruby.

ragel -R hello_world.rl

Isso irá criar um arquivo chamado hello_world.rb com o seguinte conteúdo:

# line 1 "hello_world.rl"
puts "hello world"

Eu vou deixar a execução desse arquivo como um exercício para o estudante diligente.

O Ragel na verdade faz essa conversão em dois estágios. Primeiro, ele criar um arquivo XML, então converte o XML para Ruby. Se você quer ver o XML intermediários então você pode especificar o argumento -x em adição ao argumento -R.

ragel -R -x simple_state_machine.rl > simple_state_machine.xml

Agora, vamos escrever algum código Ragel pra valer. Inicie um novo arquivo .rl ou baixe o exemplo para acompanhar. Nós vamos criar uma máquina de estados que imprime a string "hello world!" quando recebe a string "h". Para indicar ao compilar ragel que você está escrevendo instruções para ele, e não código Ruby, precisamos colocar nosso código Ragel dentro de dois sinais de porcento seguidos de chaves, %%{ e }%% , ou você pode simplesmente entrar uma instrução de uma única linha apenas digitando %%. (Veja a página 6 do Guia de Usuário.) Aqui está nossa especificação da máquina de estados:

%%{
machine hello;
expr = "h";
main := expr @ { puts "hello world!" } ;
}%%

Uma olhada rápida no que está acontecendo. O nome da máquina de estados é "hello" (o Ragel nos obrigada a nomeá-la). Ele reconhece um único token, a string "h". Quando ele encontra esse token, ele executa (em Ruby) a ação:

puts "hello world"

Agora, se você executar o ragel nesse arquivo ele compilará, mas você vai terminar com um arquivo em Ruby em branco. Nós apenas especificamos a máquina, nós também temos de dizer ao Ragel como traduzir essa máquina em código Ruby usando as declarações de escrita do Ragel. A primeira declaração de escrita que precisamos adicionar é

%% write data;

Se você adicionar essa linha depois do bloco de definição da máquina de estados, ela irá compilar, contando que você lembre-se de adicionar uma linha em branco depois. (Depois que você trabalhar com parsers por um tempo, você vai apreciar quebras de linha de uma nova forma.) Após adicionar essa linha e compilar, você deve ter um arquivo Ruby significante, com várias declarações de class << self, todas geradas pelo Ragel. Você não precisa estudar esse código, pelo menos não agora. Ele é muito idiota e feio. E se você executá-lo, você não verá nenhuma saída.

Existem mais duas declarações write para adicionar, e por conveniência, vamos colocá-los dentro de um método ruby. O argumento para esse método será a string que queremos parsear. O Ragel expera encontrar um variável chamada "data" contendo um array de códigos ASCII, então precisaremos converter nossa string em um array. Isso é feito muito facilmente em Ruby usando o método unpack.

def run_machine(data)
  data = data.unpack("c*") if data.is_a?(String)
  %% write init;
  %% write exec;
end

O write init diz ao Ragel que nós queremos gerar código de inicialização para a máquina de estados. O código Ragel gerado aqui é:

begin
  p ||= 0
  pe ||= data.length
  cs = hello_start
end

A variável p mantém o registro de qual caracter na string data nós estamos parseando agora, iniciando em 0. pe é um limite superior para p. cs mantém o estado atual da máquina de estados, e aqui é inicializado o estado de início da máquina de estados. Essas variáveis são discutidas no Guia de Usuário.

write exec diz ao Ragel para escrever o recheio do parser (finalmente!). O código gerado aqui irá realmente pegar uma entrada (o argumento data) e determinar qual deverá ser o estado do sistema baseado nessa entrada, executando quaisquer ações que possam ser disparadas pelo caminho. Vamos adicionar algumas declarações puts para que possamos seguir a execução do código.

def run_machine(data)
  data = data.unpack("c*") if data.is_a?(String)
  puts "Running the state machine with input #{data}..."

  %% write init;
  %% write exec;

  puts "Finished. The state of the machine is: #{cs}"
  puts "p: #{p} pe: #{pe}"
end

Apenas adicione mais duas linhas ao fim da chamada run_machine com vários argumentos e então finalmente poderemos compilar e executar nossa máquina de estados.

run_machine "h"
run_machine "x"

E lá vamos nós…

Running the state machine with input 104...
hello world!
Finished. The state of the machine is: 2
p: 1 pe: 1
Running the state machine with input 120...
Finished. The state of the machine is: 0
p: 0 pe: 1

Funcionou! Agora, para nos ajudar a interpretar os valores de p, pe e cs vamos dar uma olhada em um gráfico de estados dessa máquina de estados. O Ragel tem suporte embutido a Graphviz para criar gráficos de estados. Precisamos usar o argumento -V ao invés do -R.

ragel -V simple_state_machine.rl > simple_state_machine.dot

Se você renderizer o arquivo simple_state_machine.dot resultante no Graphviz, você deve obter algo semelhante a:

Nós podemos ver que essa máquina tem apenas uma transição possível, do estado 1 para o estado 2. Quando passamos "h" como parâmetro para run_machine nós terminaremos com a variável cs (current state) igual a 2 no fim de nossa execução. Quando "x" foi passado, nós terminamos com cs = 0. 0 é o estado de erro, indicando que um erro ocorreu na máquina de estados. (Você pode dizer que 0 é o estado de erro lendo algumas das atribuições de variáveis geradas pelo write data, o código que eu disse que era burro e feio.)

No label 104/4:18 sobre a seta na transição do estado 1 para o estado 2, o label 104 corresponde ao código ASCII para a letra "h". (Digite “?h” no irb.) A / indica que uma ação está sendo executada, e 4:18 nos diz que a ação inicia na linha 4, coluna 18 do arquivo .rl. Se nós tivéssemos dado um nome a nossa ação, isso teria aparecido no lugar da posição no arquivo.

A propósito, aqui está o shell script (específico do textmate) que eu usei para executar esses passos rapidamente:

ragel -R simple_state_machine.rl
ragel -V simple_state_machine.rl > simple_state_machine.dot
dot -Tpng simple_state_machine.dot > simple_state_machine.png
open simple_state_machine.png
ruby simple_state_machine.rb
mate simple_state_machine.out

Agora, tente executar esse código:

run_machine "hh"

Você deve obter:

Running the state machine with input 104104...
hello world!
Finished. The state of the machine is: 0
p: 1 pe: 2

Você não obtém "hello world!" duas vezes. Desculpe. Nossa máquina de estados está somente procurando o primeiro caractere que passamos. Ela sabe que passamos dois caracteres, demonstrado pela variável pe = 2, mas após avaliar o primeiro caractere, ela está no estado final. Não existe seta saindo do círculo no estado 2. Assim, a passagem de inputs adicionais resulta no sistema entrando no estado de erro. Se queremos que toda a string data seja executada, precisamos fazer uma pequena mudança na especificação de nossa máquina de estados.

main := expr+ @ { puts "hello world!" } ;

(Tente expr* ao invés de expr+ e veja como o gráfico de estados é diferente.)

Agora, tente executar essa nova máquina de, com as entradas "hhh" e "hxh":

Running the state machine with input 104104104...
hello world!
hello world!
hello world!
Finished. The state of the machine is: 2
p: 3 pe: 3
Running the state machine with input 104120104...
hello world!
Finished. The state of the machine is: 0
p: 1 pe: 3

Quando passamos "hhh", nós obtivemos um "hello world!" para cada "h". Quando passamos "hxh", nós obtivemos o primeiro "hello world!", mas quando chegamos ao "x" entramos no estado de erro, então o último "h" não foi avaliado.

Aqui está mais um exemplo <http://dev.agent.ie/svn/ragel/examples/multiple_state_machine.rl>, dessa vez sem definir um método run_machine:

%%{
  machine hello_and_welcome;
  main := ( 'h' @ { puts "hello world!" }
          | 'w' @ { puts "welcome" }
          )*;
}%%
  data = 'whwwwwhw'
  %% write data;
  %% write init;
  %% write exec;

welcome
hello world!
welcome
welcome
welcome
welcome
hello world!
welcome

Então, é isso. Horas de entretenimento o aguardam. Tivemos uma visão muito pequena das característica do Ragel aqui, mas você deve ser capaz de acompanhar o Guia do Usuário sem muito problema. Se você precisa de uma razão melhor que "divertimento" para brincar com o Ragel, tenha em mente que parsers são uma grande ferramenta para construir Domain Specific Languages (DSLs), e máquinas de estados são máquinas mágicas de encolhimento de código para situações onde você precisa seguir o estado de algo e controlar as mudanças entre os estados(i.e. lógica de negócio). Eu recomendaria que todos lessem esse artigo sobre o Ragel que me inspirou a estudá-lo. Se você usa Rails, então veja o plugin acts_as_state_machine que pode ser mais intuitivo que o Ragel no início. Se DSLs são a sua preferência, então você pode querer dar uma olhada no ANTLR , que tem um foco e conjunto de características diferentes do Ragel.

Pylons 0.9.6 Cheat Sheet

2008-11-16T14:40:43Z

Pylons 0.9.6 Cheat Sheet

IRC: Meet me at #pylons on irc.freenode.net as Signum

License:

Author:	Copyright (C) 2007 Dipl.-Inform. Christoph Haas <email@christoph-haas.de>
IRC:	Meet me at #pylons on irc.freenode.net as Signum
License:	This document is published under the terms of the MIT license: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. The software is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.

This document is published under the terms of the MIT license:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The software is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.

Note

O fonte desse documento está disponível em um repositório Mercurial em http://workaround.org/cgi-bin/hg-pylons-cheatsheet - por favor, envie patches para email@christoph-haas.de mesmo que você esteja lendo esse texto em wiki.pylonshq.com. Obrigado.

Contents

Pylons

Instalação

Debian/Ubuntu
- Instalação: aptitude install python-pylons (disponível no lenny/testing ou sid/unstable mas não no Etch!)
- Atualização: aptitude update && aptitude install python-pylons
Easy-Install:
- Instalação: easy_install Pylons
- Atualização: easy_install -U Pylons
virtualenv

Projeto (Paste)

Criar um novo projeto
- paster create -t pylons myapplicationsname
- Remova a página de boas vindas public/index.html
- Configure o roteamento em config/routing.py (por exemplo, colocar o '' para iniciar um controlador)
Atualizar o projeto para a nova versão do Pylons: paster create -t pylons myapplicationsname (De um diretório acima de onde o seu development.ini está localizado)
Servir a aplicação via HTTP: paster serve --reload development.ini (a aplicação executa em http://localhost:5000)
Shell interativo: paster shell (instale o ipython para facilidades adicionais)
Detalhes de como funciona a execução do Pylons

development.ini

[server:main] (Paste)
- use: aponta para o egg do servidor web do Paste
- host: O IP que irá esperar as requisições
- port: a porta TCP no qual o servidor web espera as requisições
[app:main] (Pylons)
- use: aponta para a sua aplicação
- full_stack: XXX
- cache_dir: diretório onde os templates HTML em cache e as sessões são salvas

(%(here)s refere-se a raiz do projeto (onde está o development.ini))

Acessando configurações da seção [app:main] :

from pylons import config
my_setting = config['foo.bar']

Estrutura de Diretórios

data/sessions	Sessões são salvas em arquivos nesse diretório.
data/templates	Arquivos HTML em cache que são renderizados a partir de seus templates são armazenados aqui.
development.ini	A configuração de inicialização do Paste.
myapplication/config/	Arquivos de configuração globais do seu projeto. Usados para definir rotas para o processamento de URLS, middleware (como a adição de autentição) ou o sistema de template de sua preferência
myapplication/controllers/	A localização das classes que contém a lógica da sua aplicação. Esse código controla sua aplicação, renderiza templates e consulta o banco de dados.
myapplication/docs/	Coloque qualquer documentação da aplicação aqui. De preferência no formato rest (restructured text).
myapplication/i18n/	Arquivos que lidam com as mensagens localizadas do seu projeto. (i18n = internacionalização)
myapplication/lib/	Contém arquivos que configuram certas variáveis globais e objetos que você pode usar em seus controladores. Por exemplo, tudo em lib/base.py está disponível em todos os seus controladores.
myapplication/model/	Aqui vai o model do seu banco de dados. Eles definem o esquema do banco de dados e configuram o mapeamento objeto-relacional
myapplication/public/	Arquivos estáticos como imagens, CSS ou javascripts devem ficar aqui
myapplication/templates/	Seus templates
myapplication/tests/	Cada controlador que você cria ganha uma contraparte para implementar testes automatizados aqui.
README.txt	Algumas instruções básicas que você pode dar ao administrador que irá instalar sua aplicação
ez_setup, myapplication.egg-info, setup.cfg, setup.py	Arquivos administrativos que são usados para criar um egg do seu projeto para que possa ser feito o deploy no servidor web.
test.ini	Semelhante ao development.ini. Esse arquivo é usando quando você quer rodar testes automatizados no seu projeto

Controladores

Criar um novo controlador: paster controller name-of-new-controller
O controlador mycontroller está localizado em controllers/mycontroller.py como a classe MycontrollerController
O método index é chamado quando nenhuma ação é especificada
Todos os símbolos de lib/base.py são importados
Os parâmetros definidos no Routes podem ser aceitos como argumentos:

def index(self, id):
  return 'Your ID is ' + id

Outros parâmetros estão disponíveis através de request.params['my_paramter']
Valores de retorno
- Uma string (unicode)
- Renderização de um template Mako: render('/mytemplate')
- Envio de um código de erro HTTP: abort(404)
- Um iterador (Exemplo de um StreamingController
- Redirecionando para outra URL: redirect_to(controller='start', action='about') ou redirect_to('/start/about')
Modificando o objeto de respota (a ser feito antes da declaração return da action:

response.headers['content-type'] = 'text/xml; charset=utf-8'
response.set_cookie('sitelang', 'uk')
response.status_code = 201

Objetos globais

Os dados da configuração estão disponíveis através do objeto config

Variáveis da seção app:main do development.ini:

dicionário config['app_conf']
Variáveis da seção [DEFAULT] do development.ini:

dicionário config['global_conf']
Caminho absoluto do arquivo ini: config['__file__']
Nome da aplicação: config['package'] or config['pylons.package']
Caminho para o projeto atual: config['here']
O objeto 'h' (webhelpers): config['pylons.h'] (configurado em config/environment.py)
O objeto 'g' (globals): config['pylons.g'] (configurado em config/environment.py)
A configuração do Path (onde controladores, templates e arquivos estáticos são

localizados): config['pylons.paths'] (configurado em config/environment.py)

Routes

Links
- Home
- Docs
Definidos em config/routing.py
O controlador inicial (para o caminho /) pode ser especificado como map.connect('', controller='start')
map.connect('newstoday', controller='news') -> chama ''class NewsController'' no arquivo controllers/news.py.
Argumentos adicionais são passados para o método do controlador como argumentos nomeados (e.g. def __index__(self, id, name, city):)

Mako (Templates)

Unicode
- Inicie todos os templates com : # -*- coding: utf-8 -*-
Comandos (não esqueça o ':' final)
- % for / % endfor
- % if / % elif / % else / % endif
Impressão de variáveis
- ${ c.variablename }
- The closing bracket must not be used alone on a line

Template base de exemplo (a ser herdado)

# -*- coding: utf-8 -*-
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
    <title>...........</title>
    ${ h.stylesheet_link_tag( '/style1.css', '/style2.css') }
    ${ h.javascript_include_tag( 'jquery.js', 'jquery.debug.js') }
    <link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" />
</head>
<body>
    <h1>My application</h1>
    ${ next.body() }
</body>
</html>

Herdando de um template base

# -*- coding: utf-8 -*-
<%inherit file="master.mako"/>
<p>Hello World</p>

Acesso a banco de dados

Links de documentação
- SQLAlchemy
- PostgreSQL
- MySQL
- SQLite
pylons.database e SAContext estão obsoletos!
Veja Usando SQLAlchemy com Pylons.

development.ini:

sqlalchemy.url = sqlite:///%(here)s/phonebook.db
sqlalchemy.url = mysql://username:password@host:3306/database
sqlalchemy.url = postgres://username:password@host:5432/database
sqlalchemy.url = oracle://username:password@host:1521/sidname

Opções
- O MySQL fecha conexões inativas automaticamente. Você precisará:
```
sqlalchemy.pool_recycle = 3600
```
- Imprimir todas as consultas para o console (você pode usar também o módulo 'logging' como descrito na Documentação do SQLAlchemy):
```
sqlalchemy.echo = True
```
- Lista completa de opções suportadas

Definindo tabelas e mapeamento objeto relacional in model/__init__.py

Mapeamento simples:

import sqlalchemy as sql
import sqlalchemy.orm as orm

# Define table
my_table = sql.Table(
    'tablename', metadata,
    sql.Column('id', sql.Integer, primary_key=True),    # gets a sequence/serial assigned
    sql.Column('othertable_id', sql.Integer, sql.ForeignKey("othertable.id"))
    sql.Column('name', sql.Unicode(80), nullable=False, unique=True)
)

# Define object class for ORM-mapping (every object matches one row)
class MyModel(object):
    def __repr__(self):
        return "MyModel (%s)" % self.name

orm.mapper(MyModel, my_table)

Teste o acesso aos modelos mapeados confortavelmente usando paster shell
Criando consultas e obtendo resultados
- Obter uma linha com certo conteúdo em um campo (levanta uma exceção se mais linhas são retornadas): model.Session.query(model.MyModel).filter_by(name='John').one()
- Obter um iterador de itens combinando com certo critério: model.Session.query(model.MyModel).filter(model.MyModel.name=='John')
- Obter um iterador de itens com certo conteúdo: model.Session.query(model.MyModel).filter_by(name='John')
- Obter um iterador de itens selecionados por uma condição SQL personalizada: model.Session.query(model.MyModel).filter_by("id<:value and name=:name").params(value=224, name='fred')
- Obter a linha com a chave primária 42: model.Session.query(model.MyModel).get(42)
- Obter todas as linhas: model.Session.query(model.MyModel).all()
- Obter a primeira linha: model.Session.query(model.MyModel).first()
- Obter a única linha(levanta uma exceção se mais linhas são retornadas): model.Session.query(model.MyModel).one()
- Obter um número limitado de linhas (como uma lista)
  - model.Session.query(model.MyModel).offset(50).limit(10).all()
  - model.Session.query(model.MyModel)[10:50].all()
- Ordenar linhas
  - model.Session.query(model.MyModel).order_by(model.MyModel.age).all()
  - model.Session.query(model.MyModel).order_by(model.sql.desc(model.MyModel.age)).all()
  - model.Session.query(model.MyModel).order_by([model.MyModel.age, model.MyModel.city]).all()
- Contar linhas em um resultado: model.Session.query(model.MyModel).count()
- Joins (cuidado com produtos cartesianos): model.Session.query(model.Model1, model.Model2).all()
- Use filter and filter_by for generative queries:
```
query = model.Session.query(model.MyModel)
query = query.filter_by(name='John', type=189)
query = query.filter_by(city='Hamburg')
results = query.all()
```
- Operadores lógicos
  - AND: and_(condition1, condition2, ...)
  - AND: (condition1 & condition2 & ...)
  - OR: or_(condition1, condition2, ...)
  - OR: (condition1 | condition2 | ...)
  - NOT: not_(condition)
  - NOT: ~(condition)
Operadores de consulta:
- ==
- <
- >
- <=
- >=
- startswith('foo')
- endswith('.com')
- like('%jean')
- between(100,500)
- in('A', 'CNAME', 'MX')
- + (concatenation of strings)
- op('...') (custom operator)
- ==None (NULL comparison)
Funções de consulta:
- Sintaxe geral: func.FUNCTIONNAME(...)
- e.g. func.count() or func.now()
Criando novos objetos:

new_object = model.MyModel()
new_object.name = 'Jane'
new_object.city = 'Tokio'
model.Session.flush() # not needed if set autoflush=True
model.Session.commit() # needed because SQLAlchemy 0.4 uses transactions everywhere

Alterando objetos:

old_object = model.Session.query(model.MyModel).get(42)
old_object.city = 'Paris'
model.Session.flush() # not needed if set autoflush=True
model.Session.commit() # needed because SQLAlchemy 0.4 uses transactions everywhere

Removendo objetos (não use del(...)):

old_object = model.sac.query(model.MyModel).get(42)
model.Session.delete(old_object)
model.Session.flush() # not needed if set autoflush=True
model.Session.commit() # needed because SQLAlchemy 0.4 uses transactions everywhere

Seleções arbitrárias (retorna o que você especifica ao invés de linhas completas):

query = model.sql.select([model.MyModel.some_column])
result = model.Session.execute(query).fetchall() # or .fetchmany() or .fetchone()

Tipos
- String(length=None) [é melhor usar Unicode]
- Integer
- SmallInteger
- Numeric(precision=10, length=2)
- Float(precision=10)
- DateTime [corresponds to datetime.datetime]
- Date [corresponds to datetime.date]
- Time [corresponds to datetime.time]
- Binary(length=None)
- Boolean
- Unicode(length=None)
- PickleType

Sessões baseadas em cookies

Página do Beaker
development.ini
- beaker.session.key = myproject_session (nome do cookie de sessão sendo enviado ao navegador)
- beaker.session.secret = somesecret (random string that the cookie string sent to the user is signed with)
- beaker.session.cookie_expires = True (whether the cookie is a session cookie that expires when the browser is closed)
- beaker.session.timeout = ... (time in seconds until the session times out)
- beaker.session.data_dir = ... (path where the 'sessions' directory is located storing the session data)
- beaker.session.type = ... (Storage type for session information.)
  - dbm stores sessions in files on disk
  - file stores sessions in files on disk
  - memory stores sessions in RAM
  - ext:memcached stores sessions on memcached servers. Memcache servers are configured as beaker.session.url = server1, server2, ..
A variavel session vem de pylons.session e é importada em seu lib/base.py. Ela se comporta como um dicionário.
Carregando um valor da sessão:
```
value = session['whatever']
```

Salvando um valor na sessão:

session['whatever'] = value
session.save()

Removendo uma chave da sessão:
```
del session['whatever']
session.save()
```
Limpando a sessão:
```
session.clear()
session.save()
```

Formencode

Documentação
- Sítio do Formencode
- Formulários são validados através de subclasses de formencode.schema
- Validadores customizados são normalmente subclasses de formencode.FancyValidator
- Escrevendo validadores customizados
Usando formencode:
- Defina um schema de validação
- Decore o método/ação do seu controlador (@formencode.validate(MySchema))
- Se o formulário que o usuário enviou não validar então o formencode irá reexecutare a ação atual (ou executar a ação que você especificou como form) como em @formencode.validate(MySchema, form='anotheraction') e mostrar as mensagens de erro bem acima dos inputs com uma classe CSS chamada '.error-message'
Exemplo de classe de validação:

# My form schema
class MySchema(formencode.Schema):
    allow_extra_fields = True
    filter_extra_fields = True
    days = formencode.validators.IntRange(min=0, max=365, not_empty=True)
    name = formencode.validators.MaxLength(50)

# MySchema schema without the 'days' field
class MySchema2(MySchema):
    days = None   # (removes days field from the superclass)

# MySchema schema with additional 'comment' field
class MySchema3(MySchema):
    comment = String(min=20)

Subclass variables:
- allow_extra_fields = False (whether to display an error if fields are found in the POST request that are not mentioned in this subclass)
- filter_extra_fields = False (whether to remove fields that are not mentioned in this subclass) are missing in the POST request but defined in this subclass)
- ignore_key_missing = False (whether to display an error if fields are missing in the POST request but defined in this subclass)
- if_key_missing (fields that are missing in the POST request will get this value assigned)

Bibliotecas Javascript

jQuery (pequna bibloteca Javascript com uma porção de plugins)
- Home
- Plugins
Prototype (Biblioteca Javascript)
script.aculo.us (Javascript effects library built on top of Prototype) - Home - Demos

Webhelpers

As funções de webhelpers.rails são importadas automaticamente
Controllers and templates can access the webhelpers module by the 'h' (helper) name
Links:
- Referência

Internacionalização (i18n)

Instale o Babel:
- Debian/Ubuntu: aptitude install python-pybabel (anteriormente, acidentalmente chamado de "python-babel"mas foi renomeado depois)
- Outros sistemas operacionais: easy_install Babel
Artigo do wiki
Edite o seu setup.py e habilite a seção message_extractors para interpretar strings gettext nos templates.
Use a função "_" (um alias para a função gettext) sempre que você precisar de strings normais.
- Controladores: _('Hello World')
- Templates Mako : ${ _('Hello World') }
Primeira vez:
- Criar um pot template no diretório i18n: python setup.py extract_messages
- Criar um arquivo po para cada idioma (aqui o idioma é 'es'): python setup.py init_catalog -l es
- Editar o arquivo po em i18n/es/LC_MESSAGES/*.po e adicionar strings traduzidas nos campos msgstr
- Compile the po files into mo files: python setup.py compile_catalog
Update:
- Overwrite the english pot template:: python setup.py extract_messages
- Update the po files with new strings (does not overwrite the already translated strings): python setup.py update_catalog -l es
- Compile the po files into mo files: python setup.py compile_catalog
Dica: paster serve --reload não detecta mudanças na internacionalização. Você irá precisar reiniciar o servidor web.
Para configurar a linguagem do gettext de acordo com a língua do navegador adicione isso ao seu lib/base.py:
```
def __before__(self):
    user_agent_language = request.languages[0][0:2]
    set_lang(user_agent_language)
```
request.languages is an array of preferred languages that the users sets in the browser. I.e. ['de', 'en', 'en-us'].

Testes Unitários (Nose)

Página do Nose

Comunidade

#pylons @ irc.freenode.net

Add-ons Relacionados

FormAlchemy: Cria formulários HTML automaticamente a partir de schemas do SQLAlchemy (classes mapeadas)

Paginator: Ajuda a dividir um número grande de resultados em páginas e permite que o usuário navegue entre as páginas

DBSprockets: Automaticamente cria formulários do Toscawidget e validadores do Formencode para schemas (classes mapeadas)

...

Introdução ao otimizador de consultas do PostgreSQL

2008-11-16T14:21:47Z

Introdução ao otimizador de consultas do PostgreSQL

Walter Rodrigo de Sá Cruz Criado em Wed Aug 30 11:48:04 2006

O caminho de uma consulta

Antes de entrarmos no assunto da otimização propriamente dito, precisamos rever qual é o caminho de uma consulta no banco de dados.

(A seção a seguir é adaptada da documentação do PostgreSQL)

O programa aplicativo transmite um comando para o servidor, e aguarda para receber de volta os resultados transmitidos pelo servidor.
O estágio de análise verifica o comando transmitido pelo programa aplicativo com relação à correção da sintaxe, e cria a árvore de comando.
O sistema de reescrita recebe a árvore de comando criada pelo estágio de análise, e procura por alguma regra(armazenada nos catálogos do sistema) a ser aplicada na árvore de comando. Realiza as transformações especificadas no corpo das regras. Uma das aplicações do sistema de reescrita é a criação de visões. Sempre que é executado um comando em uma visão (ou seja, uma tabela virtual), o sistema de reescrita reescreve o comando do usuário como um comando acessando as tabelas base especificadas na definição da visão, em vez da visão.
O planejador/otimizador recebe a árvore de comando (reescrita), e cria o plano de comando que será a entrada do executor. Isto é feito criando primeiro todos os caminhos possíveis que levam ao mesmo resultado. Por exemplo, se existe um índice em uma relação a ser varrido, existem dois caminhos para a varredura. Uma possibilidade é uma varredura seqüencial simples, e a outra possibilidade é utilizar o índice. Em seguida é estimado o custo de execução de cada umdos caminhos, e escolhido o mais barato. O caminho mais barato é expandido em um plano completo para que o executor possa utilizá-lo.
O executor caminha recursivamente através da árvore do plano, e traz as linhas no caminho representado pelo plano. O executor faz uso do sistema de armazenamento ao varrer as relações, realiza classificações e junções, avalia as qualificações e, por fim, envia de volta as linhas derivadas.

O papel do otimizador

(Adaptado de http://en.wikipedia.org/wiki/Query_optimizer )

O otimizador de consultas é o componente do banco de dados que tenta determinar o o modo mais eficiente de executar uma consulta.

O PostgreSQL usa algumas estatísticas mantidas em tabelas do sistema para direcionar o otimizador. Se essas estatísticas estiverem desatualizadas, você provavelmente não obterá o melhor plano para a consulta.

Para atualizar as estatísticas, devemos executar o comando ANALYZE.

É possível vermos o plano que o otimizador de consultas do PostgreSQL gerou, usando a cláusula EXPLAIN antes da consulta.

Adicionando a cláusula EXPLAIN ANALYZE antes da consulta, ela é de fato executada, de forma que possamos ter a medida do tempo.

Exemplos

Pagila

Vamos usar o banco de dados exemplo pagila, disponível em: http://pgfoundry.org/projects/dbsamples/, que é um exemplo de banco de dados de uma locadora.

Vamos começar com a configuração padrão do otimizador do Postgres. Todas as variáveis no postgresql.conf estão comentadas, o que significa que elas usarão os valores padrão.

Como teste, criei dois bancos iguais, o pagila e o pagila2, com a diferença que não rodei o ANALYZE no pagila2.

A configuração do banco é a padrão do Debian.

A consulta a seguir retorna os filmes e os atores associados a ela:

SELECT f.title, a.first_name FROM film f
INNER JOIN  film_actor ON film_actor.film_id=f.film_id
INNER JOIN actor a on film_actor.actor_id = a.actor_id

Aqui está o plano gerado para essa consulta no pagila2 (o que não recebeu ainda o ANALYZE):

Merge Join  (cost=708.95..795.88 rows=5462 width=185) (actual time=56.274..85.883 rows=5462 loops=1)
  Merge Cond: ("outer".film_id = "inner".film_id)
  ->  Sort  (cost=94.83..97.33 rows=1000 width=149) (actual time=8.489..9.926 rows=1000 loops=1)
        Sort Key: f.film_id
        ->  Seq Scan on film f  (cost=0.00..45.00 rows=1000 width=149) (actual time=0.010..4.517 rows=1000 loops=1)
  ->  Sort  (cost=614.12..627.77 rows=5462 width=42) (actual time=47.775..56.152 rows=5462 loops=1)
        Sort Key: film_actor.film_id
        ->  Merge Join  (cost=0.00..275.06 rows=5462 width=42) (actual time=0.027..33.019 rows=5462 loops=1)
              Merge Cond: ("outer".actor_id = "inner".actor_id)
              ->  Index Scan using actor_pkey on actor a  (cost=0.00..12.20 rows=200 width=44) (actual time=0.010..0.450 rows=200 loops=1)
              ->  Index Scan using film_actor_pkey on film_actor  (cost=0.00..194.08 rows=5462 width=4) (actual time=0.006..13.315 rows=5462 loops=1)
Total runtime: 94.576 ms

Sem entrar nos detalhes, vamos entender esse plano. Primeiro, temos que saber olhar de baixo pra cima.

Foi feito um index scan na tabela film_actor (a última linha)
Foi feito um index table scan na tabela actor
Essas duas tabelas foram unidas usando o algoritmo Merge Join
O resultado foi ordenado pela coluna fil,_actor.film_id
Foi feito um table scan na tabela film, e o resultado foi ordenado pela coluna film id
O resultado do scan na tabela film foi juntado com o resultado anterior, usando o algoritmo Merge Join

E aqui está o plano gerado pelo pagila (o banco no qual foi rodado o ANALYZE):

Merge Join  (cost=562.49..697.92 rows=5462 width=27) (actual time=47.691..78.064 rows=5462 loops=1)
  Merge Cond: ("outer".film_id = "inner".film_id)
  ->  Index Scan using film_pkey on film f  (cost=0.00..51.00 rows=1000 width=22) (actual time=0.011..2.442 rows=1000 loops=1)
  ->  Sort  (cost=562.49..576.15 rows=5462 width=11) (actual time=47.668..56.011 rows=5462 loops=1)
        Sort Key: film_actor.film_id
        ->  Merge Join  (cost=0.00..223.43 rows=5462 width=11) (actual time=0.025..32.304 rows=5462 loops=1)
              Merge Cond: ("outer".actor_id = "inner".actor_id)
              ->  Index Scan using actor_pkey on actor a  (cost=0.00..6.20 rows=200 width=13) (actual time=0.007..0.459 rows=200 loops=1)
              ->  Index Scan using film_actor_pkey on film_actor  (cost=0.00..148.46 rows=5462 width=4) (actual time=0.008..12.557 rows=5462 loops=1)
Total runtime: 86.610 ms

Vamos agora analizar esse plano:

Foi feito um scan na tabela film_actor pelo índice film_actor_pkey (a chave primária da tabela)
Agora, um scan na tabela actor pelo índice
As tabelas foram JOINadas pelo actor_id, e o resultado foi ordenado por film_actor.actor_id
A tabela film foi varrida pelo índice.
O resultado do JOIN anterior foi juntado com a tabela film.

Procurando clientes e filiais:

SELECT 'Filial ' || filial.store_id as filial, c.first_name || c.last_name as client FROM customer c
INNER JOIN store filial on filial.store_id = c.store_id WHERE c.active = 1

Aqui, o explain do banco sem ANALYZE:

Nested Loop  (cost=1.02..17.65 rows=1 width=84) (actual time=0.042..15.491 rows=584 loops=1)
  Join Filter: ("inner".store_id = "outer".store_id)
  ->  Seq Scan on customer c  (cost=0.00..16.49 rows=3 width=82) (actual time=0.013..1.621 rows=584 loops=1)
        Filter: (active = 1)
  ->  Materialize  (cost=1.02..1.04 rows=2 width=4) (actual time=0.002..0.006 rows=2 loops=584)
        ->  Seq Scan on store filial  (cost=0.00..1.02 rows=2 width=4) (actual time=0.004..0.011 rows=2 loops=1)
Total runtime: 16.480 ms

Repare que foi usado um materialize = um plano foi salvo num arquivo temporário.

E agora, o explain do banco com ANALYZE:

Nested Loop  (cost=4.05..46.50 rows=584 width=23) (actual time=0.175..6.097 rows=584 loops=1)
  ->  Seq Scan on store filial  (cost=0.00..1.02 rows=2 width=4) (actual time=0.008..0.015 rows=2 loops=1)
  ->  Bitmap Heap Scan on customer c  (cost=4.05..16.80 rows=300 width=21) (actual time=0.136..1.248 rows=292 loops=2)
        Recheck Cond: ("outer".store_id = c.store_id)
        Filter: (active = 1)
        ->  Bitmap Index Scan on idx_fk_store_id  (cost=0.00..4.05 rows=300 width=0) (actual time=0.122..0.122 rows=300 loops=2)
              Index Cond: ("outer".store_id = c.store_id)
Total runtime: 7.160 ms

Nesse caso, como as estatísticas já estavam atualizadas, o banco optou por uma otimização e usou o Bitmap Index Scan e o Bitmap Heap Scan.

O Bitmap Index Scan é usado em colunas que tem pouca variação (colunas de baixa cardinalidade). No caso, para cada cliente, eu tenho apenas duas opções de filias às quais ele pode estar associado (1 e 2). Então, o banco cria um mapa de bits para cada um desses valores. Esse mapa é carregado em memória, e é juntado com o resultado do table scan em store, que tem apenas dois valores possíveis.

No último select, ainda assim foi feito um Table Scan na tabela store, onde alguém poderia argumentar que seria melhor um index scan.

Random Page Cost

Existe um parâmetro de configuração, chamado random_page_cost que determina qual o peso que o PostgreSQL dá a leituras não sequencias no disco. Aumentar esse valor favorece o uso de table scans, abaixá-lo favorece o uso de índices. O valor padrão é 4.0.

Para um pequeno teste, vamos baixá-lo para 2.0 e executar a query no banco pagila.

Merge Join  (cost=0.00..42.34 rows=584 width=23) (actual time=0.128..6.012 rows=584 loops=1)
  Merge Cond: ("outer".store_id = "inner".store_id)
  ->  Index Scan using store_pkey on store filial  (cost=0.00..3.02 rows=2 width=4) (actual time=0.092..0.098 rows=2 loops=1)
  ->  Index Scan using idx_fk_store_id on customer c  (cost=0.00..27.64 rows=584 width=21) (actual time=0.015..2.150 rows=584 loops=1)
        Filter: (active = 1)
Total runtime: 6.996 ms

Como o custo do índice estava mais baixo, o otimizador preferiu usar o índice do que gerar o índice bitmap em memória.

Agora, no pagila2, o plano gerado é semelhante ao plano do banco que está com as estatísticas atualizadas:

Nested Loop  (cost=2.01..12.74 rows=1 width=84) (actual time=0.264..5.829 rows=584 loops=1)
  ->  Seq Scan on store filial  (cost=0.00..1.02 rows=2 width=4) (actual time=0.012..0.019 rows=2 loops=1)
  ->  Bitmap Heap Scan on customer c  (cost=2.01..5.82 rows=3 width=82) (actual time=0.182..1.236 rows=292 loops=2)
        Recheck Cond: ("outer".store_id = c.store_id)
        Filter: (active = 1)
        ->  Bitmap Index Scan on idx_fk_store_id  (cost=0.00..2.01 rows=3 width=0) (actual time=0.165..0.165 rows=300 loops=2)
              Index Cond: ("outer".store_id = c.store_id)
Total runtime: 6.861 ms

Executada no pagila2, a query gera o mesmo plano que havia sido gerado para random_page_cost = 4.0. E, com random_page_cost = 2.0, a primeira query do nosso teste passa a usar o índice, mesmo sem o analyze. Mas os custos não são os mesmos - isso porque o pagila2 ainda não teve as estatísticas atualizadas.

Configurações do otimizador

O arquivo de configuração do postgresql (postgresql.conf) contém várias opções que tratam da configuração do otimizador e dos vários métodos de consulta. São eles:

enable_bitmapscan

enable_hashagg

enable_hashjoin

enable_indexscan

enable_mergejoin

enable_nestloop

enable_seqscan

enable_sort

enable_tidscan

Todos eles podem ser configurados para on ou off, e por padrão todos vem habilitados. Alguns pontos a serem notados:

enable_seqscan = off não desabilita de fato o scan sequencial, já que essa pode ser a única forma de executar certas consultas. O que esse parâmetro faz ne verdade é aumentar o custo de um table scan. O mesmo vale para enable_nestloop (algumas vezes não há forma de resolver uma consulta, exceto por esse tipo de loop) e enable_sort.

Esses valores podem ser alterados em tempo de execução para uma sessão em particular, usando o comando SET.

Esse é apenas um resumo. As descrição completa das opções relativas ao otimizador são encontradas em: http://www.postgresql.org/docs/8.0/static/runtime-config.html .

Listando atores e filmes

A primeira consulta, embora trouxesse a lista de filmes e atoes, não trazia o resultado agrupado pelos filmes, com uma lista de todos os atores.

Vamor fazer essa consulta então.

Existem duas sintaxes que podem ser usadas. A primeira:

select
     film.title AS title,
     array_to_string(array_accum(actor.first_name || ' ' || actor.last_name),',') AS actors
from
     film
     inner join film_actor on film.film_id = film_actor.film_id
     inner join actor on film_actor.actor_id = actor.actor_id
GROUP BY film.title
ORDER BY film.title

E seu explain:

Sort  (cost=768.81..771.31 rows=1000 width=37) (actual time=151.996..153.650 rows=997 loops=1)
  Sort Key: film.title
  ->  HashAggregate  (cost=698.98..718.98 rows=1000 width=37) (actual time=132.534..142.902 rows=997 loops=1)
        ->  Merge Join  (cost=536.24..671.67 rows=5462 width=37) (actual time=53.739..97.676 rows=5462 loops=1)
              Merge Cond: ("outer".film_id = "inner".film_id)
              ->  Index Scan using film_pkey on film  (cost=0.00..51.00 rows=1000 width=22) (actual time=0.012..3.780 rows=1000 loops=1)
              ->  Sort  (cost=536.24..549.90 rows=5462 width=21) (actual time=53.716..63.214 rows=5462 loops=1)
                    Sort Key: film_actor.film_id
                    ->  Merge Join  (cost=0.00..197.18 rows=5462 width=21) (actual time=0.026..36.636 rows=5462 loops=1)
                          Merge Cond: ("outer".actor_id = "inner".actor_id)
                          ->  Index Scan using actor_pkey on actor  (cost=0.00..6.20 rows=200 width=23) (actual time=0.007..0.536 rows=200 loops=1)
                          ->  Index Scan using film_actor_pkey on film_actor  (cost=0.00..122.21 rows=5462 width=4) (actual time=0.009..14.883 rows=5462 loops=1)
Total runtime: 159.766 ms

Uma outra forma possível de fazer essa consulta é essa:

SELECT f.title,
array_to_string(array(select first_name FROM film_actor fa
join actor a ON fa.actor_id = a.actor_id and fa.film_id = f.film_id
),', ') as film_actor
FROM film f

Será que essa forma, além de ser menos compacta, é mais rápida também?

Seq Scan on film f  (cost=0.00..16382.69 rows=1000 width=22) (actual time=1.214..712.919 rows=1000 loops=1)
  SubPlan
    ->  Merge Join  (cost=9.56..16.34 rows=5 width=9) (actual time=0.199..0.687 rows=5 loops=1000)
          Merge Cond: ("outer".actor_id = "inner".actor_id)
          ->  Index Scan using actor_pkey on actor a  (cost=0.00..6.20 rows=200 width=13) (actual time=0.005..0.347 rows=165 loops=1000)
          ->  Sort  (cost=9.56..9.57 rows=5 width=2) (actual time=0.056..0.069 rows=5 loops=1000)
                Sort Key: fa.actor_id
                ->  Bitmap Heap Scan on film_actor fa  (cost=2.02..9.50 rows=5 width=2) (actual time=0.020..0.033 rows=5 loops=1000)
                      Recheck Cond: (film_id = $0)
                      ->  Bitmap Index Scan on idx_fk_film_id  (cost=0.00..2.02 rows=5 width=0) (actual time=0.013..0.013 rows=5 loops=1000)
                            Index Cond: (film_id = $0)
Total runtime: 714.655 ms

Parece que não.

Vemos que na consulta, o maior tempo gasto está no merge join (de 0.199 até 0.687). Vamos desabilitá-lo então. Isso é feito com o comando: set enable_mergejoin = off.

Vejamos o novo plano:

Seq Scan on film f  (cost=0.00..24679.64 rows=1000 width=22) (actual time=0.368..162.552 rows=1000 loops=1)
  SubPlan
    ->  Nested Loop  (cost=2.02..24.63 rows=5 width=9) (actual time=0.037..0.136 rows=5 loops=1000)
          ->  Bitmap Heap Scan on film_actor fa  (cost=2.02..9.50 rows=5 width=2) (actual time=0.020..0.039 rows=5 loops=1000)
                Recheck Cond: (film_id = $0)
                ->  Bitmap Index Scan on idx_fk_film_id  (cost=0.00..2.02 rows=5 width=0) (actual time=0.014..0.014 rows=5 loops=1000)
                      Index Cond: (film_id = $0)
          ->  Index Scan using actor_pkey on actor a  (cost=0.00..3.01 rows=1 width=13) (actual time=0.007..0.009 rows=1 loops=5462)
                Index Cond: ("outer".actor_id = a.actor_id)
Total runtime: 164.212 ms

Fiz um pequeno teste com o beta do PostgreSQL 8.2, e para minha surpresa, o plano gerado para essa consulta é o mesmo que é gerado no 8.1 usando enable_mergejoin = off (com random_page_cost = 2.0).

Entendendo os ícones usados no pgadmin

Escrevi uma pequena descrição para os ícones usados no pgadmin, que está disponível em: http://artigos.waltercruz.com/postgresql/explain

Outra coisa interessante pra se notar é que a grossura das setas é proporcional ao custo das operações.

Tags com o SQLAlchemy

2008-10-20T14:14:58Z

Tradução de: http://pieceofpy.com/index.php/2008/10/09/tags-with-sqlalchemy/

Existem diversos artigos da Net sobre SQLalchemy. Implementação de um blog, um wiki, mesmo outros artigos sobre a implementação de tags. Alguns são bons, outros bem pobres, e alguns apenas estão desatualizados. Após alguma pesquisa sobre as melhores práticas sobre como implementar um sistema de Tags com o SQLalchemy eu cheguei à solução que você está prestes a ler.

Eu extraí esse exemplos de um código real em produção. Apenas renomeei e resumi um pouco para esse post. Peguei a convenção de nomes do exemplo SimpleSite do Pylons. Aqui está o layout das tabelas. Simples. Uma página, tag, e tabela de relação.

page_table = sa.Table("page", meta.metadata,
    sa.Column("id", sa.types.Integer, sa.schema.Sequence('page_seq_id', optional=True), primary_key=True),
    sa.Column("name", sa.types.Unicode(100), nullable=False),
)

tag_table = sa.Table("tag", meta.metadata,
    sa.Column("id", sa.types.Integer, sa.schema.Sequence('taq_seq_id', optional=True), primary_key=True),
    sa.Column("name", sa.types.Unicode(50), nullable=False, unique=True),
)

pagetag_table = sa.Table("pagetag", meta.metadata,
    sa.Column("id", sa.types.Integer, sa.schema.Sequence('pagetag_seq_id', optional=True), primary_key=True),
    sa.Column("pageid", sa.types.Integer, sa.schema.ForeignKey('page.id')),
    sa.Column("tagid", sa.types.Integer, sa.schema.ForeignKey('tag.id')),
)

Agora, a parte importente, o mapeamento. O mapeador é o que diz ao sqlalchemy o que você está tentando fazer e como relacionar essas ForeignKeys. Ele faz o trabalho pesado por você.

class Tag(object):
    pass

class Page(object):
    pass

orm.mapper(Tag, tag_table)
orm.mapper(Page, page_table, properties = {
    'tags':orm.relation(Tag, secondary=pagetag_table, cascade="all,delete-orphan"),
})

Isso faz duas coisas. Configura o relacionamento e também usa a regra built-in de cascata do SQLalchemy para garantir que não existam tags órfãs no banco de dados.

Agora podemos usar o modelo que configuramos. Aqui, eu apenas iniciei meu paster shell para que eu pudesse trabalhar alguns exemplos de uso.

page = model.Page()
page.name = "Example Page"

tag = model.Tag()
name = "tag"

page.tags.append(tag)
meta.Session.save(page)
meta.Session.commit()

tag_q = meta.Session.query(model.Tag)
tags = tag_q.all()
len(tags)

# filter pages by tag(s)
page_q = meta.Session.query(model.Page)
pages = page_q.join('tags').filter_by(name="tag").all()

# delete-orphans does the work for us here...
meta.Session.delete(pages[0])
meta.Session.commit()

tags = tag_q.all()
len(tags)

# tag cloud anyone?
# see the source code linked below for a properly weighted tag cloud.
tag_q = meta.Session.query(func.count("*").label("tagcount"), model.Tag)
tag_r = tag_q.filter(model.Tag.id==model.pagetag_table.c.tagid).group_by(model.Tag.id).all()

# what about pages with related tags?
page_q = meta.Session.query(model.Page)

taglist = ["tag1", "tag2"]
tagcount = len(taglist)
page_q.join(model.Page.tags).filter(model.Tag.name.in_(taglist)).\
group_by(model.Page.id).having(func.count(model.Page.id) == tagcount).all()

Ok, agora a parte divertida, e sobre todas as tags relacionadas? Uma intersecção entre um número arbitrário de relacionamentos muitos para muitos? Para isso eu adicionei um método estático a minha classe. Algo assim:

class Tag(object):
    @staticmethod
    def get_related(tags=[]):
        tag_count = len(tags)

        inner_q = select([pagetag_table.c.pageid])
        inner_w = inner_q.where(
            and_(pagetag_table.c.tagid == Tag.id,Tag.name.in_(tags))
        ).group_by(pagetag_table.c.pageid).having(func.count(pagetag_table.c.pageid) == tag_count).correlate(None)

        outer_q = select([Tag.id, Tag.name, func.count(pagetag_table.c.shipid)])
        outer_w = outer_q.where(
            and_(pagetag_table.c.pageid.in_(inner_w),
            not_(Tag.name.in_(tags)),
            Tag.id == pagetag_table.c.tagid)
        ).group_by(pagetag_table.c.tagid)

        related_tags = meta.Session.execute(outer_w).fetchall()
        return related_tags

Um grande agradecimento ao CakePHP e ao TagSchema pelas idéias, conceitos e exemplos de implementação.

Você pode encontrar o código real no qual esse texto foi baseado em: http://trac.pieceofpy.com/pieceofpy/browser/tags-sqlalchemy