Notas de lançamento do Django versão 0.96¶
Bem-vindo (a) à versão 0.96 do Django
O primeiro objetivo para o 0.96 é limpar e estabilizar as características introduzidas na versão 0.95. Houveram algumas backwards-incompatible changes desde a 0.95, mas o processo de atualização deve ser razoavelmente simples e não deve requerer uma grande mudança nas aplicações existentes.
Contudo, estamos também disponibilizando 0.96 agora pois temos várias alterações retro-incompatíveis agendadas para breve. Assim que concluídas, elas envolverão algumas alterações no código para desenvolvedores de aplicações, assim sendo, recomendamos que você continue com Django 0.96 até a próxima versão oficial; então será possível atualizar em um passo ao invés de fazer alterações incrementais para continuar com a versão de desenvolvimento do Django.
Alterações retro-incompatíveis.¶
Para as próximas alterações, pode ser necessário atualizar seu código ao sair da versão 0.95 para a 0.96:
MySQLdb
versão solicitada.¶
Devido um bug nas versões anteriores do módulo MySQLdb
para Python (que é utilizado pelo Django para se conectar à base de dados MySQL), o backend de MySQL do Django agora requer versão 1.2.1p2, ou superior, do módulo “MySQLdb. Caso sejam utilizadas verões anteriores a esta, ocorrerão excessões.
Caso você não possa atualmente atualizar a cópia do “MySQLdb” para satisfazer essas necessidades, um backend retro-compatível separado, chamado, “mysql_old”, foi adicionado ao Django. Para utilizar este backend, altere as configurações em DATABASE_ENGINE
no arquivo settings de:
DATABASE_ENGINE = "mysql"
para:
DATABASE_ENGINE = "mysql_old"
Contudo, é altamente encorajado por nós que os usuários de MySQL, atualizem o módulo “MySQLdb” o quanto antes. O backend “mysql_old serve apenas para facilitar a transição e é considerado deprecated; ou seja, fora correções de segurança, ele não será ativamente mantido e será removido em uma futura versão do Django.
Note ainda que algumas funções como a nova configuração DATABASE_OPTIONS
(veja o :doc: documentação de base dados </ref/databases> para detalhes) só está disponível para o backend “mysql”, não estando dispoível para “mysql_old”.
Nomes de restrição de dados alterados¶
O formato dos nomes das regras gerados pelo Django para referenciar chaves estrangeiras foram ligeiramente alteradas. Estes nomes, em geral, são usados somente quando não é possível colocar a referência diretamente na coluna afetada, de modo que não estão visíveis sempre.
O resultado disso é que ao executar manage.py reset
e comandos similares em um banco de dados existente talvez gerará um SQL com o novo formato de nome do “constraint”, enquanto que o banco de dados existente contém nomes no formato antigo; isso irá fazer com que o banco de dados gere uma mensagem de erro sobre modificar “constraints” não existentes
Se você precisar contornar isso, há dois métodos disponíveis:
- Redirecione a saída de “manage.py” para um arquivo e edite o SQL gerado para corrigir as constraints antes de executá-lo.
- Verifique a saída de
manage.py sqlall
para ver o novo estilo para os nomes de constraint e utilize isso como um guia para renomear as constraints existentes em sua base de dados.
Nomes alterados em “manage.py”¶
Algumas das opções de “manage.py” foram alteradas com o adição de suporte a fixture:
- Existem novos comandos “dumpdata” e “loaddata” que, como se pode imaginar, irão realizar dump’s e load’s de dados de/para a base de dados. Estes comandos, podem operar em qualquer formato de serialização que seja suportada pelo Django.
- O comando
sqlinitialdata
foi renomeado parasqlcustom
para enfatizar que oloaddata
deve ser usado para dados (e osqlcustom
para outros SQL customizados – views, stored procedures, etc.). - O comando
install
foi removido. Usesyncdb
.
Escape da contrabarra modificado¶
O banco de dados de API Django agora escapa barras invertidas fornecidas como parâmetros na consulta. Se tiver algum código de API de banco de dados que coincida com barras invertidas, e ele estava funcionando antes (apesar da falta de escapar), você vai ter que alterar seu código para “não escapar” as barras em um nível.
Por exemplo, isto costumava funcionar:
# Find text containing a single backslash
MyModel.objects.filter(text__contains="\\\\")
Agora, o código acima está incorreto, e deve ser reescrito como:
# Find text containing a single backslash
MyModel.objects.filter(text__contains="\\")
O que há de novo na 0.96?¶
Esta correção representa mais de mil commits e mais de quatrocentos correções de bugs, assim não é fácil catalogar todas estas alterações. Aqui, estão descritas apenas as alterações mais relevantes este lançamento.
Biblioteca de novas formas¶
django.newforms
é a nova biblioteca de form-handling do Django. É a substituta do django.forms
, o antigo framework de formularios, manipuladores e validadores. Ambas as APIs estão disponíveis na 0,96, mas ao longo dos próximos dois lançamentos pretendemos mudar completamente para o novo sistema de formulários e tornar depreciado e remover o antigo sistema.
Há três elementos para essa transição:
Nós copiamos o atual
django.forms
paradjango.oldforms
. Isto permite você atualizar seu código agora ao invés de esperar quando não tiver compatibilidade com versões anteriores e ter que se apressar para corrigir seu código após este fato. Apenas altere suas declarações de import com esta:from django import forms # 0.95-style from django import oldforms as forms # 0.96-style
O próximo lançamento oficial do Django irá mover o atual
django.newforms
paradjango.forms
. Isto será uma alteração não compatível com versões anteriores, e alguem ainda usando versões mais velhas dodjango.forms
naquele momento irá precisar alterar as declrações de import como descrito acima.O próximo lançamento após o que irá remover completamente
django.oldforms
.
Embora a biblioteca newforms
continue evoluindo, ela está pronta para uso na maioria dos casos. Recomendamos que novos formulários deixe de usar o antigo sistema e já inicie com o novo sistema de formulários.
Para mais informações sobre` django.newforms`, leia a documentação newforms.
Melhorias URLconf¶
Agora você pode usar qualquer requisição como retorno de requisição no URLconfs (anteriormente, somente strings que referia-se a requisições era permitido). Isto permite um uso muito mais natural do URLconfs. Por exemplo, este URLconf:
from django.conf.urls.defaults import *
urlpatterns = patterns("", ("^myview/$", "mysite.myapp.views.myview"))
Agora pode ser reescrita como:
from django.conf.urls.defaults import *
from mysite.myapp.views import myview
urlpatterns = patterns("", ("^myview/$", myview))
Uma aplicação útil disso pode ser visto quando se utiliza decoradores; esta mudança permite que você aplique decoradores de views *em seu URLconf *. Assim, você pode fazer uma view genérica requerer login facilmente:
from django.conf.urls.defaults import *
from django.contrib.auth.decorators import login_required
from django.views.generic.list_detail import object_list
from mysite.myapp.models import MyModel
info = {
"queryset": MyModel.objects.all(),
}
urlpatterns = patterns("", ("^myview/$", login_required(object_list), info))
Note-se que ambas syntaxes (strings e callables) são válidos, e continuará a ser válido para o futuro previsível.
O teste framework¶
Django now includes a test framework so you can start transmuting fear into
boredom (with apologies to Kent Beck). You can write tests based on
doctest
or unittest
and test your views with a simple test client.
There is also new support for “fixtures” – initial data, stored in any of the supported serialization formats, that will be loaded into your database at the start of your tests. This makes testing with real data much easier.
Veja a documentação the testing para ver os detalhes completos.
Melhorias para a interface de administrador¶
Uma pequena mudança, mas muito bacana: views dedicadas para adicionar e atualizar usuários foram adicionadas a interface do admin, então você não precisa se preocupar em trabalhar com senhas hash no admin.
Obrigado¶
Since 0.95, a number of people have stepped forward and taken a major new role in Django’s development. We’d like to thank these people for all their hard work:
- Russell Keith-Magee and Malcolm Tredinnick for their major code contributions. This release wouldn’t have been possible without them.
- Our new release manager, James Bennett, for his work in getting out 0.95.1, 0.96, and (hopefully) future release.
- Our ticket managers Chris Beaven (aka SmileyChris), Simon Greenhill, Michael Radziej, and Gary Wilson. They agreed to take on the monumental task of wrangling our tickets into nicely cataloged submission. Figuring out what to work on is now about a million times easier; thanks again, guys.
- Everyone who submitted a bug report, patch or ticket comment. We can’t possibly thank everyone by name – over 200 developers submitted patches that went into 0.96 – but everyone who’s contributed to Django is listed in AUTHORS.