Migrando de Django 1.5 a 1.11

Javier Daza
Python Barranquilla

¿Por qué actualizar tu software?

Seguridad: Correcciones de vulnerabilidades
Mejoras: Arreglo de errores y mejoras del producto

Enfoques

¿Cuales serían tus estrategias para migrar la aplicación?

Enfoques

Crea un nuevo proyecto en la versión mas reciente de Django, pega tus modelos ahi y cruza los dedos
Poco a poco, ve subiendo a la siguiente versión de Django de tu proyecto

Django
1.5

Notas de la versión

Se puede extender el modelo User o reemplazarlo por uno personalizado
Primer soporte "experimental" a Python 3
Model.save() ahora acepta el argumento update_fields para especificar que campos se escriben a la DB.
El motor de template interpreta True, False y None com sus correspondientes objetos de Python

Cambios incompatibles hacia atrás

ALLOWED_HOSTS se requiere en producción. Cuando DEBUG sea False
Queda deprecado el uso de django.utils.simplejson por json

Para mayor información ve a Django 1.5 release notes

Si no usas SECRET_KEY en los settings, te aparecerá un Warning

Adicionales

Django
1.6

Notas de la versión

Se han simplificado y modernizado las plantillas por defecto de startproject y startapp.
Conexiones persistentes en la DB. Se permite reutilizar una conexión para varias peticiones.
Nuevo runner de Tests, django.test.runner.DiscoverRunner. Ahora podrás correr los tests en cualquier modulo cuyo nombre encaje al patrón test*.py.
GeoDjango provee de form fields y widgets para sus campos geo-especializados.

Desuso

El algoritmo de Model.save() cambió. Si existe una pk intenta hacer un UPDATE directamente. Ahora se usa 1 query en vez de 2.
El metodo get_or_create no requiere, al menos, un argumento

Para mayor información ve a Django 1.6 release notes

Se dejará de soportar django.contrib.comments

Django
1.7

Notas de la versión

Migraciones. El comando syncdb será reemplazado por migrate. Se utilizará un nuevo comando llamado makemigrations.
Métodos QuerySet desde el Manager
Nuevo System check framwork. Se utiliza para validar proyectos de Django, deteca problemas comunes y te da pistas para arreglarlos.
Nuevo objeto Prefetch para personalizar operaciones con prefetch_related()

Warnings por usar SITE_ID, MANAGERS, TEMPLATE_LOADERS, ADMINS o XFrameOptionsMiddleware. Agregar BASE_DIR.
Mejoras en el comando runserver
- En sistemas Linux, si tienes instalado pyinotify, el servidor de desarrollo cargará automáticamente, no habrá un pequeño delay
- Automáticamente recargará las traducciones
- Todas las peticiones HTTP se mostrarán en la consola
El método QuerySet.update_or_create fue añadido

Para mayor información ve a Django 1.7 release notes

Cambios incompatibles hacia atrás

Scripts WSGI

Se removieron los sgtes Middlewares del default:
- SessionMiddleware
- AuthenticationMiddleware
- MessageMiddleware

# ANTES

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

# AHORA

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Django
1.8

Notas de la versión

Soporta Python 3.5
Nuevos tipos de datos
- UUIDField para guardar identificadores únicos universales
- DurationField para guardar periodos de tiempo modelados en Python por timedelta.
Expresiones en los queries
Condicionales en los queries (WHEN y CASE).

WarniFunciones de bases de datos, como Coalesce, Concat y Substr.
Se eliminan django.contrib.comments. Recomiendo reemplazarlos por django_comments en INSTALLED_APPS.
EL comando runserver usa hilos daemon para recargar más rápido.
select_related ahora verifica que el campo dado exista en realidad

Para mayor información ve a Django 1.8 release notes

Notas de la versión

Cambian las django.conf.urls.patterns()
- Pasan de ser tuplas a listas

# ANTES

urlpatterns = patterns('',
    url('^$', 'myapp.views.myview'),
)

# AHORA

from django.conf.urls import url
from myapp import views

urlpatterns = [
    url('^$', views.myview),
    url('^other/$', views.otherview),
]

Django
1.9

Notas de la versión

Realizando acciones luego de una transacción con la DB. Es útil para tareas como enviar emails, crear tareas en cola o invalidar caches.
Validador de contraseñas AUTH_PASSWORD_VALIDATORS
Nuevo diseño del administrador.
Se pueden correr tests en paralelo en multiples procesos.

Las migraciones iniciales se marcan con un initial = True para ayudar a migrate --fake-initial a detectarlas fácilmente.
En el settings.py las tuplas se volvieron listas
- La variable TEMPLATES pasa a ser una lista, incluyendo las variables TEMPLATES_DIRS,
  TEMPLATE_LOADERS, TEMPLATE_CONTEXT_PROCESSORS
  y TEMPLATE_DEBUG entre otras.
- MIDDLEWARE_CLASSES también pasaron a ser una lista

Para mayor información ve a Django 1.9 release notes

Django
1.10

Notas de la versión

Búsqueda de texto completo para PostgreSQL
Reemplazar STATIC_URL por
- load static en vez de load staticfiles o load static from staticfiles
- <img src="{% static 'img/imagen.png' %}">
MIDDLEWARE_CLASSES cambian a MIDDLEWARE. La sintaxis para hacer personalizados también cambió
Soporte en UNICODE para Usernames

Se añade soporte para Argon2 password hash (no viene instalado por defaul porque requiere librerias de terceros).
Quitaron los hashers de contraseña débiles de la configuración predeterminada PASSWORD_HASHERS

Para mayor información ve a Django 1.10 release notes

Cambios incompatibles hacia atrás

Select_related() prohíbe campos no relacionales para relaciones anidadas
runserver ahora pasa por logging. Ahora maneja las peticiones y respuestas por medio de django.server. Si sobreescribres el logging o lo personalizas, recuerda tomar las medidas para ver el output del runserver también

Django
1.11

Notas de la versión

La serie de Django 1.11.x es la última en soportar Python 2.x. La próxima versión de Django, Django 2.0 solo soportará desde Python 3.5
Las advertencias de descontinuación ya no aparecerán por defecto.
La nueva opción loaddata --exclude permite excluir modelos y aplicaciones mientras se cargan datos de fixtures.

Las migraciones se añade soporte para la serialización de objetos uuid.UUID.
Jinja2 ahora soporte context_processors.
GDAL ahora es requerido como dependencia para GeoDjango.
PostgreSQL 9.3 será la mínima versión que soporte
Se quita el soporte para settings.TIME_ZONE = None.
Se empezará a advertir las excepciones {% include %} cuando se haga render. Ya no serán silenciosas.

Para mayor información ve a Django 1.11 release notes

Recomendaciones finales

Ver el plan de obsoletos (deprecated plan)
Ver en la documentación de tu host sugerencias sobre como hacer las migraciones.
Hacer backup de tus datos
Tener bastante paciencia