RSS

Escribiendo tu primera aplicación (app) Django, parte 1 – Traducción

06 Ago

Hola, quiero compartir con ustedes este intento de traducción que hice sobre el tutorial de como hacer nuestra primera aplicación con Django. Pido disculpas si hay algún error, de cualquier tipo, y de ser así, por favor avísenme. Muchas gracias, a continuación lo que pretende ser la traducción.

El tutorial es este: https://docs.djangoproject.com/en/1.5/intro/tutorial01/

DJANGO 1.5

 Escribiendo tu primera aplicación (app) Django, parte 1

Aprendamos por ejemplo.

A través de este tutorial, te llevaremos a través de la creación de una aplicación básica de encuesta.

Consistirá en dos partes:

  • Un sitio público que va a permitir a la gente ver la encuesta y votar en ella
  • Un sitio admin que te permitirá añadir, cambiar y borrar la encuesta

Asumimos que ya tenés Django instalado. Podés decir que Django está instalado y qué versión corriendo el siguiente comando:

python -c “import django; print(django.get_version())”

Si Django está instalado, deberías ver la versión de tu instalación. Si no lo está, tendrás un error diciéndote “No module named django”, “Ningún módulo llamado django”.

Este tutorial está escrito para Django 1.5 y Python 2.x. Si la versión de Django no coincide, puedes referirte al tutorial para tu versión de Django o actualizar Django a la nueva versión. Si estás usando Python 3.x, ten en cuenta que tu código puede necesitar diferir de lo que hay en este tutorial y deberías continuar usando el tutorial solo si sabes que es lo que estás haciendo con Python 3.x.

Ver How to install Django (Cómo instalar Django) para consejos en como eliminar (remover) viejas versiones de Django e instalar una nueva.

Dónde conseguir ayuda: Si estás teniendo problemas a través de este tutorial, por favor postee (deje) un mensaje en django-users o pasa por #django en irc.freenode.net para chatear con otros usuarios Django que podrán ser capaces de ayudarte.

Creando un proyecto

Si esta es tu primera vez usando Django, deberás tener cuidado de la configuración inicial. A saber, necesitarás auto-generar código que establecerán el proyecto Django – una colección de configuraciones para instancias de Django, incluyendo configuración de base de datos, opciones específicas de Django y configuraciones específicas de aplicaciones.

Desde la línea de comandos, cd hacia el directorio en dónde te gustaría almacenar tu código, luego corre el siguiente comando:

django-admin.py startproject mysite

Esto creará el directorio mysite en el directorio actual. Si no funciona, mira Problems running django-admin.py, “Problemas corriendo django-admin.py”.

Nota: Necesitarás evitar nombrar proyectos luego de usar funciones de Python o componentes Django. En particular, esto significa que deberías evitar nombres como django (que conflictuará con Django mismo) o test (que conflictuará con funciones de los paquetes de Python).
Dónde debería vivir este código?: Si tu antecedente es simple y viejo PHP (sin uso de frameworkds modernos), estarás acostumbrado a colocar código en la raíz de documentos del servidor Web (en un lugar como /var/www). Con Django, no hacés eso. No es buena idea poner cualquiera de estos códigos Python en la raíz de documentos del servidor Web, porque corre riesgo de que la gente pueda ver tu código en la Web. Eso no es bueno para la seguridad.Pon tu código en un directorio aparte del directorio raíz, como /home/mycode.

Veamos lo que creó startproject:

mysite/

manage.py

mysite/

__init__.py

settings.py

urls.py

wsgi.py

No coincide con lo que ves?: El proyecto por default cambió recientemente. Si estás viendo una disposición plana (sin el directorio mysite/), probablemente estás usando una versión de Django que no coincide con esta versión del tutorial. Vos decidirás cambiar a la versión vieja del tutorial o a la versión nueva de Django.

Estos archivos son:

  • El directorio raíz exterior mysite/ es el contenedor del proyecto. Ese nombre no le interesa a Django; lo podés renombrar como quieras.
  • manage.py es un comando que te permite interactuar con este proyecto de Django de varias formas. Podés leer todo lo relacionado a manage.py en este enlace.
  • El directorio interno mysite/ es el paquete actual de Python para tus proyectos. Su nombre es el nombre de paquete de Python que necesitarás usar para importar cualquier cosa dentro de él (ej: mysite.urls).
  • mysite/__init__.py: Es un archivo vacío que le dice a Python que este directorio debe ser considerado un paquete Python. (Lea más sobre paquetes en la documentación oficial de Python si eres nuevo en Python).
  • mysite/settings.py: Settings/configuración para este proyecto Django. Configuración de Django te dirá todo sobre como funcionan las configuraciones.
  • mysite/urls.py: Las declaraciones URL para este proyecto Django; una “tabla de contenidos” de tu sitio Django-powered (impulsado por Django). Puedes leer más sobre URLs en URL dispatcher.
  • mysite/wsgi.py: Un punto de entrada para los servidores web compatibles con WSGI de tu proyecto. Lee más sobre How to deploy with WSGI (Cómo implementar WSGI) para más detalles.

El servidor de desarrollo

Comprobemos que esto funcionaba. Cámbiate al directorio externo mysite, si es que no lo hiciste, y corre el comando python manage.py runserver. Verás la siguiente salida en la línea de comando:

Validating models…

0 errors found

August 05, 2013 – 15:50:53

Django version 1.5, using settings ‘mysite.settings’

Development server is running at http://127.0.0.1:8000/

Quit the server with CONTROL-C.

Inicializaste el servidor de desarrollo de Django, un servidor web ligero escrito puramente en Python. Incluimos esto con Django así puedes desarrollar cosas rápidamente, sin tener que lidiar con configuraciones de server de producción – como Apache – hasta que estés listo para la producción.

Ahora es un buen momento para notar: No uses este servidor en un entorno de producción. Está destinado sólo para uso de desarrollo. (Estamos en el negocio de crear Web frameworks, no servidores Web).

Ahora que el servidor corre, visita http://127.0.0.1:8000/ con tu navegador Web. Verás la página “Welcome to Django”, en un agradable, azúl pastel claro. It worked!.

Cambiando el puerto:Por defecto, el comando runserver inicializa el servidor de desarrollo en la IP interna en el puerto 8000.Si quieres cambiar el puerto del servidor, pásalo como argumento en la línea de comando. Por ejemplo, este comando inicializa el servidor en el puerto 8080:python manage.py runserver 8080Si quieres cambiar la IP del servidor, pásalo junto con el puerto. Para así poder escucharlo en todas las IPs públicas (útil si quieres mostrar tu trabajo en otras computadoras), usa:python manage.py runserver 0.0.0.0:8080Documentos completos de servidor de desarrollo pueden ser encontrados en la referencia runserver.

Configuración de Base de Datos

Ahora, edita mysite/settings.py. Es un módulo de Python normal con las variables de nivel de módulo que representan las configuraciones de Django. Cambia los siguientes ítems de las llaves en DATABASES ‘default’ para que coincida con la configuración de conexiones de tu base de datos.

  • ENGINE – O ‘django.db.backends.postgresql_psycopg2’, ‘django.db.backends.mysql’, ‘django.db.backedns.sqlite3’ o ‘django.db.backends.oracle’. Otros backends están disponibles.
  • NAME – El nombre de tu base de datos. Si estás usando SQLite, la base de datos será un archivo en tu computadora; en ese caso, NAME debe ser la ruta completa, incluyendo el nombre de archivo, de ese archivo. Si el archivo no existe, se creará automáticamente cuando sincronices la base de datos por primera vez (ver abajo).
    Cuando especificamos la ruta, siempre usamos la barra invertida /, incluso en Windows (ej: C:/homes/user/mysite/sqlite3.db).
  • USER – El nombre de usuario de la base de datos (no es necesario en SQLite).
  • PASSWORD – El password de tu base de datos (no es necesario en SQLite).
  • HOST – El host en donde se encuentra tu base de datos. Deja esto como una cadena vacía (o posiblemente 127.0.0.1) si tu servidor de base de datos está físicamente en la misma máquina (no es necesario en SQLite). Vea HOST para más detalles.

Si eres nuevo en base de datos, te recomendamos simplemente usar SQLite configurando ENGINE con ‘django.db.backends.sqlite3‘ y en NAME el lugar donde te gustaría almacenar tu base de datos. SQLite está incluído en Python, así que no tendrás la necesidad de instalar nada que de soporte a tu base de datos.

Nota: Si estás usando PostreSQL o MySQL, asegúrate de que creaste la base de datos para éste punto. Para eso hacelo con “CREATE DATABASE database_name;” dentro del sistema interactivo de la base de datos.Si estás usando SQLite, no necesitas crear nada de antemano – el archivo de base de datos será creado automáticamente cuando sea necesario.

Mientras estás editando settings.py, configura TIME_ZONE de acuerdo a tu zona horaria. El valor por defecto es la zona horaria Central de U.S. (Chicago).

También, notese que la configuración INSTALLED_APPS está hacia el final del archivo. Este contiene los nombres de todas las aplicaciones de Django que están activadas en esta instancia de Django. Las aplicaciones pueden ser usadas en múltiples proyectos, y la puedes empaquetar y distribuir para que sean usadas por otros en sus proyectos.

Por defecto, INSTALLED_APPS contiene las siguientes aplicaciones, todos los cuales vienen con Django:

  • django.contrib.auth – Un sistema de autenticación
  • django.contrib.contenttypes – Un framework para tipos de contenido
  • django.contrib.sessions – Un framework de sesiones
  • django.contrib.sites – Un framework para administrar múltiples sitios con una instalación Django
  • django.contrib.messages – Un framework de mensajería
  • django.contrib.staticfiles – Un framework para administrar archivos estáticos

Estas aplicaciones están incluidas por defecto para una conveniencia de caso común.

Cada una de estas aplicaciones hacen uso de al menos una tabla de la base de datos, aunque, así que necesitamos crear las tablas en la base de datos antes de que podamos usarlas. Para hacer eso, ejecutamos el siguiente comando:

python manage.py syncdb

El comando syncdb mira hacia la configuración de INSTALLED_APPS y crea cualquier tabla base de datos necesaria acorde a la configuración de la base de datos en tu archivo mysite/settings.py. Verás un mensaje por cada tabla creada en la base de datos, y verás un mensaje en el prompt preguntándote si quieres crear una cuenta de superusuario para la autenticación del sistema. Adelante y hazlo.

Si estás interesado, ejecuta el cliente para tu base de datos en la línea de comando y escribe \dt (PostreSQL), SHOW TALBES; (MySQL), o .schema (SQLite) para mostrar las tablas creadas de Django.

Para los minimalistas: Como dijimos más arriba, las aplicaciones por defecto son incluidas para el caso común, pero no todos necesitan esto. Si no necesitas alguno o a todos, siéntete libre de comentarlas o borrar las líneas apropiadas de INSTALLED_APPS antes de ejecutar syncdb. El comando syncdb sólo creará tablas para las aplicaciones en INSTALLED_APPS.

Creando modelos

Ahora que tu ambiente – el “proyecto” – está configurado, estás listo para empezar a trabajar.

Cada aplicación que escribas en Django consiste en un paquete Python, en algún lugar de tu ruta Python, que sigue una cierta convención. Django viene con una utilidad que automáticamente genera el directorio con la estructura básica para una aplicación, así puedes focalizarte en escribir el código en vez de crear directorios.

Proyectos vs aplicaciones: Cuál es la diferencia entre un proyecto y una aplicación? Una aplicación es una aplicación Web que hace algo – ej: un sistema Weblog, una base de datos de registros públicos o una aplicación de encuestas. Un proyecto es una colección de configuración y aplicaciones para un sitio Web en particular. Un proyecto puede contener múltiples aplicaciones. Una aplicación puede estar en múltiples proyectos.

Tus aplicaciones pueden vivir en cualquier lugar de la ruta de Python. En este tutorial, crearemos nuestra aplicación de encuesta junto a tu archivo manage.py así puede ser importado como su propio módulo de nivel superior, en vez de submódulo de mysite.

Para crear tu aplicación, asegúrate de estar en el mismo directorio que manage.py y escribe este comando:

python manage.py startapp polls

Eso creará el directorio polls, que luce de esta manera:

polls/

__init__.py

models.py

tests.py

views.py

La estructura de este directorio albergará la aplicación poll.

El primer paso en escribir una base de datos de una aplicación Web en Django es la de definir tus modelos – esencialmente, la disposición de tu base de datos, con metadata adicional.

Filosofía: Un modelo es la simple, fuente definitiva de información acerca de tus datos. Contiene los campos esenciales y comportamientos de la información que estás almacenando. Django sigue DRY Principle. La meta es definir el modelo de dato en un lugar y automáticamente manejar las cosas desde ahí.

En nuestra simple aplicación poll, crearemos dos modelos: Poll y Choice. Poll tiene la pregunta (question) y la fecha de publicación (publication date). Choice tiene dos campos: el texto de la elección (choice) y el recuento de votos (vote tally). Cada Choice es asociada con un Poll.

Estos conceptos son representados por simple clases Python. Edite el archivo polls/models.py para que se vea de la siguiente forma:

from django.db import modelsclass Poll(models.Model):question = models.CharField(max_length=200)pub_question = models.DateTimeField(‘date published’)class Choice(models.Model):poll = models.ForeignKey(Poll)choice_text = models.CharField(max_length=200)votes = models.IntegerField(default=0)

El código es sencillo. Cada modelo es representado por una clase que es subclase de django.db.models.Model. Cada modelo tiene un número de variables de clases, cada uno representa un campo de la base de datos en el modelo.

Cada campo es representado por una instancia de la clase Field, ej: para un campo caracter CharField y DateTimeField para datetimes. Ésto le dice a Django que tipo de dato contiene cada campo.

El nombre de cada instancia Field (ej: question o pub_date) es el nombre del campo, en formato máquina-amigable. Vas a usar este valor en tu código Python, y tu base de datos lo usará como nombre de columna.

Puedes usas el primer argumento posicional opcional a un Field para designar un nombre humano-legible. Que se utiliza en un par de piezas introspectivas de Django, y se utiliza como documentación. Si este campo no es previsto, Django usará el nombre máquina-legible. En este ejemplo, definiremos un nombre humano-legible para Poll.pub_date. Para todos los otros campos en este modelo, el nombre del campo máquina-legible será suficiente como nombre humano-legible.

Algunas clases Field requieren argumentos. CharField, por ejemplo, requiere que le de max_length. Que se utiliza no sólo en el esquema de base de datos, pero en la validación, como pronto veremos.

Field puede tener varios argumentos opcionales, en este caso, hemos establecido el valor de votos 0 por defecto.

Finalmente, note la relación que se define, usando ForeignKey. Que le dice a Django que cada Choice está relacionado a un sólo Poll. Django soporta todas las bases comunes de las bases de datos: many-to-ones (muchos a uno), many-to-many (muchos a muchos) y one-to-ones (uno a uno).

Activando modelos

Esta pequeña porción de código le da a Django mucha información. Con esto, Django es capaz de:

  • Crear un esquema de base de datos (sentencia CREATE TABLE) para esta aplicación.
  • Crear una API Python de acceso de base de datos para acceder a los objetos Poll y Choice.

Pero primero necesitamos decirle a nuestro proyecto que las aplicaciones de polls están instaladas.

Filosofía: Las aplicaciones de Django son “conectables”: Puedes usar una aplicación en múltiples proyectos, y puedes distribuir aplicaciones, porque no tienen que estar vinculados a una instalación de Django.

Edita el archivo settings.py otra vez, y cambia la configuración INSTALLED_APPS para incluir la cada ‘polls‘. Para que luzca de la siguiente manera:

INSTALLED_APPS = (‘django.contrib.auth’,‘django.contrib.contenttypes’,‘django.contrib.sessions’,‘django.contrib.sites’,‘django.contrib.messages’,‘django.contrib.staticfiles’,# Uncomment the next line to enable the admin:# ‘django.contrib.admin’,# Uncomment the next line to enable admin documentation:# ‘django.contrib.admindocs’,‘polls’,)

Ahora Django sabe para incluir las aplicaciones polls. Ejecutemos otro comando:

python manage.py sql polls

Deberías ver algo similar a lo siguiente (las sentencias SQL CREATE TABLE para las aplicaciones polls):

BEGIN;CREATE TABLE “polls_poll” (id” serial NOT NULL PRIMARY KEY,question” varchar(200) NOT NULL,pub_date” timestamp with time zone NOT NULL);CREATE TABLE “polls_choice” (id” serial NOT NULL PRIMARY KEY,poll_id” integer NOT NULL REFERENCES “polls_poll” (“id”) DEFERRABLE INITIALLY DEFERRED,choice_text” varchar(200) NOT NULL,votes” integer NOT NULL);COMMIT;

Note lo siguiente:

  • La salida exacta va a variar dependiendo de la base de datos que esté usando.
  • Los nombres de las tablas son automáticamente generados combinando el nombre de la aplicación (polls) y el nombre en minúsculas del modelo poll y choice. (Puedes sobreescribir este comportamiento).
  • Llaves primaria (IDs) son añadidas automáticamente. (Puedes sobreescribir esto, también).
  • Por convención, Django añade “_id” al campo llave foránea. (Si, podés sobreescribir esto, también).
  • La relación de claves foráneas se hace explícita por funciones de REFERENCIAS.
  • Se adapta a la base de datos que está usando, para los tipos de campo específicos de base de datos como auto_increment (MySQL), serial (PostrgreSQL), o integer primary key (SQLite) son manejados automáticamente por vos. Lo mismo va para los nombres de campos con comillas – ej: usando doble comillas o comillas simples. El autor de este tutorial corre PostgreSQL, por lo que el ejemplo de salida tiene la sintaxis PostrgreSQL.
  • El comando sql no funciona en realidad no ejecuta el SQL en tu base de datos – solo imprime por pantalla para que puedas ver lo que SQL Django requiere. Si lo deseas, puedes copiar y pegar este SQL en el prompt de tu base de datos. Sin embargo, como veremos brevemente, Django provee una manera fácil de commitear el SQL a la base de datos.

Si estás interesado, también puedes correr los siguientes comandos:

  • python manage.py validate: Chequea por cualquier error en la construcción de los modelos.
  • python manage.py sqlcustom polls: Emite las sentencias SQL personalizadas (como las modificaciones en tablas o restricciones) que son definidas por la aplicación.
  • python manage.py sqlclear polls: Emite las funciones DROP TABLE necesarias para estas aplicaciones, de acuerdo a las tablas que ya existen en tu data base (si alguno).
  • python manage.py sqlindexes polls: Emite las funciones CREATE INDEX para esta aplicación.
  • python manage.py sqlall polls: Una combinación de todos los comandos SQL: sql, sqlcustom, y sqlindexes.

Viendo las salidas de esos comandos puede ayudarte a entender que pasa en realidad bajo la cubierta.

Ahora, ejecuta syncdb otra vez para crear esos modelos de tablas en tu base de datos:

python manage.py syncdb

El comando syncdb ejecuta SQL de sqlall en tu base de datos para todas las aplicaciones en INSTALLED_APPS que aún no existen en tu base de datos. Esto crea todas las tablas, datos iniciales e indexaciones para cualquier aplicaciones que hayas añadido a tu proyecto desde la última vez que ejecutaste syncdb. syncdb puede ser llamado tan seguido como quieras, y sólo creará las tablas que no existen.

Lee la documentación de django-admin.py para más información sobre lo que manage.py puede hacer.

Jugando con las API

Ahora, vamos a la shell interactiva de Python y juguemos con las aplicaciones gratuitas que Django te ofrece. Para invocar la shell de Python, usa el este comando:

python manage.py shell

Estamos usando esto en vez simplemente escribir “python”, porque manage.py configura las variables del ambiente DJANGO_SETTINGS_MODULE, que le da a Django la ruta de Python para importar a tu archivo mysite/settings.py.

Evitando manage.py: Si prefieres no usar manage.py, no hay problema. Sólo configura el ambiente DJANGO_SETTINGS_MODULE la variable mysite.settings y ejecuta python desde el mismo directorio en donde se encuentra manage.py (o asegúrate de que ese directorio se encuentra en la ruta de Python, así import mysite funciona).Para más información de todo esto, lee la documentación de adjango-admin.py.

Una vez que estés en la shell, explora la API de la base de datos:

>>> from polls.models import Poll, Choice # Import the model classes we just wrote# No polls are in the system yet>>> Poll.objects.all()[]# Create a new Poll# Support for time zones is enabled in the default settings file, so# Django expects a datetime with tzinfo for pub_date. Use timezone.now()# instead of datetime.datetime.now() and it will do the right thing.>>> from django.utils import timezone>>> p = Poll(question=”What’s new?”, pub_date=timezone.now())# Save the object into the database. You have to call save() explicitly>>> p.save()# Now it has an ID. Note that this might say “1L” instead of “1”, depending# on which database you’re using. That’s no biggie; it just means your# database backend prefers to return integers as Python long integer# objects.>>> p.id1# Access database columns via Python attributes>>> p.questionWhat’s new?”>>> p.pub_datedatetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)# Change values by changing the attributes, then calling save()>>> p.question = “What’s up?”>>> p.save()# objects.all() displays all the polls in the database>>> Poll.objects.all()[<Poll: Poll object>]

Espera un minuto. <Poll: Poll object> es, absolutamente, una representación inútil de este objeto. Arreglemos eso editando el modelo poll (en el archivo polls/models.py) y añadir el método __unicode__() tanto en Poll y en Choice:

class Poll(models.Model):# …def __unicode__(self):return self.questionclassChoice(models.Model): # …def__unicode__(self):return self.choice_text

Es importante añadir los métodos __unicode__() a tus modelos, no solo para tu propia salud mental cuando lidias con la consola interactiva, sino también porque la representación de objetos son usados en toda la administración de Django generada automáticamente.

Por qué __unicode__() y no __str__()?: Si estás familiarizado con Python, debes tener el hábito de añadir métodos __str__() a tus clases, no métodos __unicode__(). Usamos __unicode__() aquí porque los modelos Django tratan con Unicode por defecto. Toda la información almacenada en la base de datos es convertida a Unicode cuando es retornada.Los modelos Django tienen por defecto el método __str__() que llama a __unicode__() y convierte el resultado a bytestring UTF-8.Si todo esto es una algarabía para tí, sólo recuerda añadir métodos __unicode__() a tus modelos. Con un poco de suerte, las cosas deberían funcionar para tí.

Nótese que estos son modelos normal en Python. Añadamos métodos personalizados, sólo para demostración:

import datetimefrom django.utils import timezone# …class Poll(models.Model): # …def was_published_recently(self):return self.pub_date >= timezone.now() – datetime.timdelta(days=1)

Note la añadidura de import datetie y from django.utils import timezone, que referencia al módulo standard de Python y a las utilidades relacionadas a la zona horaria de Django en django.utils.timezone, respectivamente. Si no estás familiarizados con el manejo de la zona horaria en Python, puedes aprender más en time zone support docs.

Guarda estos cambios e inicia una nueva shell interactiva de Python ejecutando python manage.py shell otra vez:

>>> from polls.models import Poll, Choice# Make sure our __unicode__() addition worked>>> Poll.objects.all()[<Poll: What’s up?>]# Django provides a rich database lookup API that’s entirely driven by# keyword arguments>>> Poll.objects.filter(id=1)[<Poll: What’s up?>]>>> Poll.objects.filter(question__startswith=’What’)[<Poll:What’s up?>]# Get the poll that was published this year>>> from django.utils import timezone>>> current_year = timezone.now().year>>> Poll.objects.get(pub_date__year=current_year)<Poll: What’s up?># Request an ID that doesn’t exist, this will raise an exception>>> Poll.objects.get(id=2)Traceback (most recent call last):DoesNotExist: Poll matching query does not exist. Lookup parameters were {‘id’: 2}# Looup by a primary key is the most common case, so Django provides a# shortcut for primary-key exact lookups# The following is identical to Poll.objects.get(id=1)>>> Poll.objects.get(pk=1)<Poll: What’s up?>]# Make sure our custom method worked>>> p = Poll.objects.get(pk=1)>>> p.was_published_recently()True# Give the Poll a couple of Choices. The create call constructs a new# Choice object, does the INSERT statement, adds the choice to the set# of available choices and returns the new Choice object. Django creates# a set to hold the “other side” of a ForeignKey relation# (e.g. a poll’s choices) which can be accessed via the API>>> p = Poll.objects.get(pk=1)# Display any choices from the related object set – none so far>>> p.choice_set.all()[]# Create three choices>>> p.choice_set.create(choice_text=’Not much’, votes=0)<Choice: Not much>>>> p.choice_set.create(choice_text=’The sky’, votes=0)<Choice: The sky>>>> c = p.choice_set.create(choice_text=’Just hacking again’, votes=0)# Choice objects have API access to their related Poll objects>>> c.poll<Poll: What’s up?># And vice versa: Poll objects get access to Choice objects>>> p.choice_set.all()[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>>> p.choice_set.count()3# The API automatically follows relationships as far as you need.# Use double underscores to separate relationships.# This works as many levels deep as you want; there’s no limit.# Find all Choices for any poll whose pub_date is in this year# (reusing the ‘current_year’ variable we created above).>>> Choice.objects.filter(poll__pub_date__year=current_year)[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]# Let’s delete one of the choices. Use delete() for that.>>> c = p.choice_set.filter(choice_text__startswith=’Just hacking’)>>> c.delete()

Para más información de modelos de relación, lea Accessing related objects. Para más información sobre como usar el doble guió bajo para realizar búsquedas de campos a través de las API, leer Field lookups. Para detalles completos sobre API de base de datos, lea Database API reference.

 

Etiquetas: , , ,

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: