Configurar la Base de Datos

Introducción

Este tutorial comienza donde dejó Creación de una aplicación de sondeo básica. Configuraremos la base de datos, crearemos nuestro primer modelo y obtendremos una rápida introducción al sitio de administración automáticamente generado de Django.

Configuración de la base de datos

Ahora, abra mysite/settings.py. Es un módulo de Python normal con variables de nivel de módulo que representan las configuraciones de Django.

Por defecto, la configuración utiliza SQLite. Si es nuevo en bases de datos o solo está interesado en probar Django, esta es la opción más fácil. SQLite está incluido en Python, por lo que no necesitará instalar nada más para admitir su base de datos. Sin embargo, al comenzar su primer proyecto real, es posible que desee usar una base de datos más escalable, como PostgreSQL, para evitar problemas al cambiar de base de datos más adelante.

Si desea usar otra base de datos, instale los enlaces de base de datos <database-installation> adecuados y cambie las siguientes claves en el elemento 'default' de DATABASES para que coincidan con sus configuraciones de conexión a la base de datos:

• ENGINE <DATABASE-ENGINE> -- Puede ser 'django.db.backends.sqlite3', 'django.db.backends.postgresql', 'django.db.backends.mysql' o 'django.db.backends.oracle'. También están disponibles otros backends .
• NAME -- El nombre de su base de datos. Si está usando SQLite, la base de datos será un archivo en su computadora; en ese caso, NAME debe ser la ruta absoluta completa, incluyendo el nombre de archivo, de ese archivo. El valor predeterminado, BASE_DIR / 'db.sqlite3', almacenará el archivo en el directorio de su proyecto.

Si no está usando SQLite como su base de datos, deben agregarse ajustes adicionales, como USER, PASSWORD y HOST. Para obtener más detalles, consulte la documentación de referencia de DATABASES.

Para bases de datos diferentes a SQLite

Si está usando una base de datos diferente a SQLite, asegúrese de haber creado una base de datos en este momento. Haga eso con "CREATE DATABASE database_name;" dentro del prompt interactivo de su base de datos.

También asegúrese de que el usuario de la base de datos proporcionado en mysite/settings.py tenga privilegios de "crear base de datos". Esto permite la creación automática de una base de datos de prueba <the-test-database> que se necesitará en un tutorial posterior.

Si está usando SQLite, no necesita crear nada previamente: el archivo de base de datos se creará automáticamente cuando sea necesario.

Mientras edita mysite/settings.py, establezca TIME_ZONE en su zona horaria.

También, observe la configuración INSTALLED_APPS en la parte superior del archivo. Esa contiene los nombres de todas las aplicaciones de Django que se activan en esta instancia de Django. Las aplicaciones se pueden usar en múltiples proyectos y se pueden empaquetar y distribuir para que otros las usen en sus proyectos.

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

• django.contrib.admin -- El sitio de administración. Lo usará pronto.
• django.contrib.auth -- Un sistema de autenticación.
• django.contrib.contenttypes -- Un marco para tipos de contenido.
• django.contrib.sessions -- Un marco de sesiones.
• django.contrib.messages -- Un marco de mensajes.
• django.contrib.staticfiles -- Un marco para administrar archivos estáticos.

Estas aplicaciones se incluyen por defecto como una conveniencia para el caso común.

Sin embargo, algunas de estas aplicaciones utilizan al menos una tabla de base de datos, por lo que necesitamos crear las tablas en la base de datos antes de poder utilizarlas. Para hacer eso, ejecute el siguiente comando:

cd ~/project/mysite
python manage.py migrate

Operaciones a realizar:
  Aplicar todas las migraciones: admin, auth, contenttypes, sessions
Ejecutando migraciones:
  Aplicando contenttypes.0001_initial... OK
  Aplicando auth.0001_initial... OK
  Aplicando admin.0001_initial... OK
  Aplicando admin.0002_logentry_remove_auto_add... OK
  Aplicando admin.0003_logentry_add_action_flag_choices... OK
  Aplicando contenttypes.0002_remove_content_type_name... OK
  Aplicando auth.0002_alter_permission_name_max_length... OK
  Aplicando auth.0003_alter_user_email_max_length... OK
  Aplicando auth.0004_alter_user_username_opts... OK
  Aplicando auth.0005_alter_user_last_login_null... OK
  Aplicando auth.0006_require_contenttypes_0002... OK
  Aplicando auth.0007_alter_validators_add_error_messages... OK
  Aplicando auth.0008_alter_user_username_max_length... OK
  Aplicando auth.0009_alter_user_last_name_max_length... OK
  Aplicando auth.0010_alter_group_name_max_length... OK
  Aplicando auth.0011_update_proxy_permissions... OK
  Aplicando auth.0012_alter_user_first_name_max_length... OK
  Aplicando sessions.0001_initial... OK

El comando migrate examina la configuración INSTALLED_APPS y crea cualquier tabla de base de datos necesaria de acuerdo con las configuraciones de la base de datos en su archivo mysite/settings.py y las migraciones de la base de datos enviadas con la aplicación (veremos eso más adelante). Verá un mensaje para cada migración que aplica. Si está interesado, ejecute el cliente de línea de comandos de su base de datos y escriba \dt (PostgreSQL), SHOW TABLES; (MariaDB, MySQL), .tables (SQLite) o SELECT TABLE_NAME FROM USER_TABLES; (Oracle) para mostrar las tablas que Django creó.

Para los minimalistas

Como dijimos anteriormente, las aplicaciones predeterminadas se incluyen para el caso común, pero no todos necesitan todas ellas. Si no necesita ninguna o todas ellas, puede comentar o eliminar la línea adecuada de INSTALLED_APPS antes de ejecutar migrate. El comando migrate solo ejecutará migraciones para las aplicaciones en INSTALLED_APPS.

Creando modelos

Ahora definiremos nuestros modelos, esencialmente, la estructura de nuestra base de datos, con metadatos adicionales.

Un modelo es la única fuente definitiva de información sobre nuestros datos. Contiene los campos y comportamientos esenciales de los datos que estamos almacenando. Django sigue el Principio DRY <dry>. El objetivo es definir nuestro modelo de datos en un solo lugar y derivar automáticamente cosas a partir de él.

Esto incluye las migraciones: a diferencia de Ruby On Rails, por ejemplo, las migraciones se derivan enteramente de su archivo de modelos y son esencialmente una historia que Django puede revisar para actualizar su esquema de base de datos para que coincida con sus modelos actuales.

En nuestra aplicación de sondeo, crearemos dos modelos: Question (Pregunta) y Choice (Elección). Una Pregunta tiene una pregunta y una fecha de publicación. Una Elección tiene dos campos: el texto de la elección y un recuento de votos. Cada Elección está asociada a una Pregunta.

Estos conceptos se representan por clases de Python. Edite el archivo polls/models.py para que se vea así:

from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField("date published")


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

Aquí, cada modelo se representa por una clase que hereda de django.db.models.Model. Cada modelo tiene un número de variables de clase, cada una de las cuales representa un campo de base de datos en el modelo.

Cada campo se representa por una instancia de una clase ~django.db.models.Field; por ejemplo, ~django.db.models.CharField para campos de texto y ~django.db.models.DateTimeField para fechas y horas. Esto le dice a Django qué tipo de datos almacena cada campo.

El nombre de cada instancia de ~django.db.models.Field (por ejemplo, question_text o pub_date) es el nombre del campo, en un formato amigable para la máquina. Usará este valor en su código de Python y su base de datos lo usará como el nombre de la columna.

Puede usar un primer argumento posicional opcional para una ~django.db.models.Field para designar un nombre legible para humanos. Eso se utiliza en un par de partes introspectivas de Django y también sirve como documentación. Si este campo no se proporciona, Django usará el nombre legible para la máquina. En este ejemplo, solo hemos definido un nombre legible para humanos para Question.pub_date. Para todos los demás campos de este modelo, el nombre legible para la máquina del campo será suficiente como nombre legible para humanos.

Algunas clases ~django.db.models.Field tienen argumentos requeridos. ~django.db.models.CharField, por ejemplo, requiere que le dé un ~django.db.models.CharField.max_length. Eso se utiliza no solo en el esquema de base de datos, sino también en la validación, como veremos pronto.

Un ~django.db.models.Field también puede tener varios argumentos opcionales; en este caso, hemos establecido el valor predeterminado ~django.db.models.Field.default de votes en 0.

Finalmente, observe que se define una relación, usando ~django.db.models.ForeignKey. Eso le dice a Django que cada Elección está relacionada con una sola Pregunta. Django admite todas las relaciones de base de datos comunes: muchos a uno, muchos a muchos y uno a uno.

Activando modelos

Ese pequeño código de modelo le da a Django mucha información. Con él, Django es capaz de:

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

Pero primero debemos decirle a nuestro proyecto que la aplicación polls está instalada.

Las aplicaciones de Django son "pluggables": Puede usar una aplicación en múltiples proyectos y puede distribuir aplicaciones, porque no tienen que estar vinculadas a una instalación de Django determinada.

Para incluir la aplicación en nuestro proyecto, debemos agregar una referencia a su clase de configuración en la configuración INSTALLED_APPS. La clase PollsConfig está en el archivo polls/apps.py, por lo que su ruta puntual es 'polls.apps.PollsConfig'. Edite el archivo mysite/settings.py y agregue esa ruta puntual a la configuración INSTALLED_APPS. Se verá así:

INSTALLED_APPS = [
    "polls.apps.PollsConfig",
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
]

Ahora Django sabe que debe incluir la aplicación polls. Vamos a ejecutar otro comando:

python manage.py makemigrations polls

Debería ver algo similar a lo siguiente:

Migrations for 'polls':
  polls/migrations/0001_initial.py
    - Create model Question
    - Create model Choice

Al ejecutar makemigrations, está diciendo a Django que ha hecho algunos cambios en sus modelos (en este caso, ha creado nuevos) y que desea que los cambios se almacenen como una migración.

Las migraciones son la forma en que Django almacena los cambios en sus modelos (y por lo tanto en su esquema de base de datos); son archivos en el disco. Puede leer la migración de su nuevo modelo si lo desea; es el archivo polls/migrations/0001_initial.py. No se preocupe, no se espera que los lea cada vez que Django los hace, pero están diseñados para ser editables por humanos en caso de que desee ajustar manualmente cómo Django cambia las cosas.

Hay un comando que ejecutará las migraciones por usted y gestionará automáticamente su esquema de base de datos; se llama migrate, y llegaremos a él en un momento, pero primero, veamos qué SQL ejecutaría esa migración. El comando sqlmigrate toma los nombres de las migraciones y devuelve su SQL:

python manage.py sqlmigrate polls 0001

Debería ver algo similar a lo siguiente (lo hemos reformateado para mayor legibilidad):

BEGIN;
--
-- Create model Question
--
CREATE TABLE "polls_question" (
    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
    "question_text" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);
--
-- Create model Choice
--
CREATE TABLE "polls_choice" (
    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
    "choice_text" varchar(200) NOT NULL,
    "votes" integer NOT NULL,
    "question_id" bigint NOT NULL
);
ALTER TABLE "polls_choice"
  ADD CONSTRAINT "polls_choice_question_id_c5b4b260_fk_polls_question_id"
    FOREIGN KEY ("question_id")
    REFERENCES "polls_question" ("id")
    DEFERRABLE INITIALLY DEFERRED;
CREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" ("question_id");

COMMIT;

Tenga en cuenta lo siguiente:

• La salida exacta variará según la base de datos que esté usando. El ejemplo anterior se genera para PostgreSQL.
• Los nombres de las tablas se generan automáticamente combinando el nombre de la aplicación (polls) y el nombre en minúsculas del modelo: question y choice. (Puede anular este comportamiento.)
• Las claves primarias (IDs) se agregan automáticamente. (También puede anular esto.)
• Por convención, Django agrega "_id" al nombre del campo de clave externa. (Sí, también puede anular esto.)
• La relación de clave externa se hace explícita por una restricción FOREIGN KEY. No se preocupe por las partes DEFERRABLE; está diciendo a PostgreSQL que no enforce la clave externa hasta el final de la transacción.
• Está adaptado a la base de datos que está usando, por lo que los tipos de campo específicos de la base de datos como auto_increment (MySQL), bigint PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY (PostgreSQL) o integer primary key autoincrement (SQLite) se manejan automáticamente para usted. Lo mismo ocurre con la citación de los nombres de los campos, por ejemplo, usando comillas dobles o simples.
• El comando sqlmigrate no ejecuta realmente la migración en su base de datos; en cambio, la imprime en la pantalla para que pueda ver qué SQL Django piensa que es necesario. Es útil para comprobar lo que Django va a hacer o si tiene administradores de base de datos que requieren scripts SQL para los cambios.

Si está interesado, también puede ejecutar python manage.py check <check>; esto comprueba si hay algún problema en su proyecto sin hacer migraciones ni tocar la base de datos.

Ahora, ejecute migrate nuevamente para crear esas tablas de modelo en su base de datos:

python manage.py migrate

Operations to perform:
  Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Applying polls.0001_initial... OK

El comando migrate toma todas las migraciones que no se han aplicado (Django rastrea cuáles se han aplicado usando una tabla especial en su base de datos llamada django_migrations) y las ejecuta en su base de datos, esencialmente, sincronizando los cambios que hizo en sus modelos con el esquema en la base de datos.

Las migraciones son muy poderosas y le permiten cambiar sus modelos con el tiempo, a medida que desarrolla su proyecto, sin necesidad de eliminar su base de datos o tablas y crear nuevas; se especializa en actualizar su base de datos en vivo, sin perder datos. Lo cubriremos en mayor profundidad en una parte posterior del tutorial, pero por ahora, recuerde la guía de tres pasos para hacer cambios en los modelos:

• Cambie sus modelos (en models.py).
• Ejecute python manage.py makemigrations <makemigrations> para crear migraciones para esos cambios.
• Ejecute python manage.py migrate <migrate> para aplicar esos cambios a la base de datos.

La razón de que haya comandos separados para crear y aplicar migraciones es porque se enviarán las migraciones a su sistema de control de versiones y se enviarán con su aplicación; no solo facilitan su desarrollo, sino que también son utilizables por otros desarrolladores y en producción.

Lea la documentación de django-admin </ref/django-admin> para obtener información completa sobre lo que puede hacer la utilidad manage.py.

Jugando con la API

Ahora, vamos a entrar en el shell interactivo de Python y jugar con la API gratuita que Django le ofrece. Para invocar el shell de Python, use este comando:

python manage.py shell

Estamos usando esto en lugar de simplemente escribir "python", porque manage.py establece la variable de entorno DJANGO_SETTINGS_MODULE, que le da a Django la ruta de importación de Python a su archivo mysite/settings.py.

Una vez que estás en el shell, explora la API de base de datos </topics/db/queries>:

>>> from polls.models import Choice, Question  ## Importa las clases de modelo que acabamos de escribir.

## No hay preguntas en el sistema todavía.
>>> Question.objects.all()
<QuerySet []>

## Crea una nueva Pregunta.
## El soporte para zonas horarias está habilitado en el archivo de configuración predeterminado, por lo que
## Django espera una fecha y hora con tzinfo para pub_date. Use timezone.now()
## en lugar de datetime.datetime.now() y hará lo correcto.
>>> from django.utils import timezone
>>> q = Question(question_text="¿Qué hay de nuevo?", pub_date=timezone.now())

## Guarda el objeto en la base de datos. Tienes que llamar a save() explícitamente.
>>> q.save()

## Ahora tiene un ID.
>>> q.id
1

## Accede a los valores de los campos del modelo a través de atributos de Python.
>>> q.question_text
"¿Qué hay de nuevo?"
>>> q.pub_date
datetime.datetime(2023, 9, 7, 1, 18, 48, 335644, tzinfo=datetime.timezone.utc)

## Cambia los valores cambiando los atributos, luego llama a save().
>>> q.question_text = "¿Qué pasa?"
>>> q.save()

## objects.all() muestra todas las preguntas en la base de datos.
>>> Question.objects.all()
<QuerySet [<Question: Pregunta objeto (1)>]>

Espera un minuto. <Question: Pregunta objeto (1)> no es una representación útil de este objeto. Vamos a arreglar eso editando el modelo Question (en el archivo polls/models.py) y agregando un método ~django.db.models.Model.__str__ a tanto Question como Choice:

from django.db import models


class Question(models.Model):
    #...
    def __str__(self):
        return self.question_text


class Choice(models.Model):
    #...
    def __str__(self):
        return self.choice_text

Es importante agregar métodos ~django.db.models.Model.__str__ a sus modelos, no solo por su propia conveniencia al trabajar con el prompt interactivo, sino también porque las representaciones de los objetos se usan en todo el administrador automáticamente generado de Django.

Vamos a agregar también un método personalizado a este modelo:

import datetime

from django.db import models
from django.utils import timezone


class Question(models.Model):
    #...
    def was_published_recently(self):
        return self.pub_date >= timezone.now() - datetime.timedelta(days=1)

Tenga en cuenta la adición de import datetime y from django.utils import timezone, para referenciar el módulo datetime estándar de Python y las utilidades relacionadas con las zonas horarias de Django en django.utils.timezone, respectivamente. Si no está familiarizado con el manejo de zonas horarias en Python, puede aprender más en la documentación de soporte de zonas horarias </topics/i18n/timezones>.

Guarda estos cambios y comienza un nuevo shell interactivo de Python ejecutando python manage.py shell nuevamente:

>>> from polls.models import Choice, Question

## Asegúrate de que nuestra adición de __str__() funcione.
>>> Question.objects.all()
<QuerySet [<Question: ¿Qué pasa?>]>

## Django proporciona una rica API de búsqueda de base de datos que está completamente impulsada por
## argumentos de palabras clave.
>>> Question.objects.filter(id=1)
<QuerySet [<Question: ¿Qué pasa?>]>
>>> Question.objects.filter(question_text__startswith="¿Qué")
<QuerySet [<Question: ¿Qué pasa?>]>

## Obtén la pregunta que se publicó este año.
>>> from django.utils import timezone
>>> current_year = timezone.now().year
>>> Question.objects.get(pub_date__year=current_year)
<Question: ¿Qué pasa?>

## Solicita un ID que no existe, esto generará una excepción.
>>> Question.objects.get(id=2)
Traceback (most recent call last):
 ...
DoesNotExist: Pregunta que coincide con la consulta no existe.

## La búsqueda por clave primaria es el caso más común, por lo que Django proporciona un
## atajo para búsquedas exactas por clave primaria.
## Lo siguiente es idéntico a Question.objects.get(id=1).
>>> Question.objects.get(pk=1)
<Question: ¿Qué pasa?>

## Asegúrate de que nuestro método personalizado funcione.
>>> q = Question.objects.get(pk=1)
>>> q.was_published_recently()
True

## Da a la Pregunta un par de Elecciones. La llamada a create construye un nuevo
## objeto Choice, hace la instrucción INSERT, agrega la elección al conjunto
## de elecciones disponibles y devuelve el nuevo objeto Choice. Django crea
## un conjunto para mantener el "lado opuesto" de una relación ForeignKey
## (por ejemplo, las elecciones de una pregunta) que se puede acceder a través de la API.
>>> q = Question.objects.get(pk=1)

## Muestra cualquier elección del conjunto de objetos relacionados, ninguna hasta ahora.
>>> q.choice_set.all()
<QuerySet []>

## Crea tres elecciones.
>>> q.choice_set.create(choice_text="No mucho", votes=0)
<Choice: No mucho>
>>> q.choice_set.create(choice_text="El cielo", votes=0)
<Choice: El cielo>
>>> c = q.choice_set.create(choice_text="Volviendo a hackear", votes=0)

## Los objetos Choice tienen acceso a través de la API a sus objetos Question relacionados.
>>> c.question
<Question: ¿Qué pasa?>

## Y viceversa: Los objetos Question tienen acceso a los objetos Choice.
>>> q.choice_set.all()
<QuerySet [<Choice: No mucho>, <Choice: El cielo>, <Choice: Volviendo a hackear>]>
>>> q.choice_set.count()
3

## La API sigue automáticamente las relaciones tan lejos como sea necesario.
## Utiliza dos guiones bajos para separar las relaciones.
## Esto funciona tantos niveles de profundidad como desees; no hay límite.
## Encuentra todas las Elecciones para cualquier pregunta cuya pub_date esté en este año
## (reutilizando la variable 'current_year' que creamos anteriormente).
>>> Choice.objects.filter(question__pub_date__year=current_year)
<QuerySet [<Choice: No mucho>, <Choice: El cielo>, <Choice: Volviendo a hackear>]>

## Vamos a eliminar una de las elecciones. Usa delete() para eso.
>>> c = q.choice_set.filter(choice_text__startswith="Volviendo a hackear")
>>> c.delete()

Para obtener más información sobre las relaciones de modelo, consulte Accediendo a objetos relacionados </ref/models/relations>. Para más sobre cómo usar dos guiones bajos para realizar búsquedas de campos a través de la API, consulte Búsquedas de campos <field-lookups-intro>. Para obtener detalles completos sobre la API de base de datos, consulte nuestra Referencia de API de base de datos </topics/db/queries>.

Presentando el Administrador de Django

Generar sitios de administración para su personal o clientes para agregar, cambiar y eliminar contenido es un trabajo tedioso que no requiere mucha creatividad. Por esa razón, Django automatiza por completo la creación de interfaces de administración para los modelos.

Django fue escrito en un entorno de redacción, con una clara separación entre "editores de contenido" y el sitio "público". Los administradores del sitio usan el sistema para agregar noticias, eventos, puntuaciones deportivas, etc., y ese contenido se muestra en el sitio público. Django resuelve el problema de crear una interfaz unificada para que los administradores del sitio editen el contenido.

El administrador no está destinado a ser utilizado por los visitantes del sitio. Es para los administradores del sitio.

Creando un usuario administrador

Primero necesitaremos crear un usuario que pueda iniciar sesión en el sitio de administración. Ejecute el siguiente comando:

python manage.py createsuperuser

Ingrese el nombre de usuario deseado y presione Enter.

Nombre de usuario: admin

Luego se le solicitará su dirección de correo electrónico deseada:

Dirección de correo electrónico: admin@example.com

El último paso es ingresar su contraseña. Se le pedirá que ingrese su contraseña dos veces, la segunda vez como confirmación de la primera.

Contraseña: 12345678
Contraseña (nuevamente): 12345678

Esta contraseña es muy común.
Esta contraseña es completamente numérica.
¿Saltar la validación de contraseña y crear el usuario de todos modos? [y/N]: y
Superusuario creado con éxito.

Iniciar el servidor de desarrollo

El sitio de administración de Django está activado por defecto. Vamos a iniciar el servidor de desarrollo y explorarlo.

Si el servidor no está en ejecución, inícielo así:

python manage.py runserver

Ahora, abra un navegador web en la pestaña VNC y vaya a "/admin/" en su dominio local, por ejemplo, http://127.0.0.1:8000/admin/. Debería ver la pantalla de inicio de sesión del administrador:

Dado que la traducción </topics/i18n/translation> está activada por defecto, si establece LANGUAGE_CODE, la pantalla de inicio de sesión se mostrará en el idioma dado (si Django tiene las traducciones adecuadas).

Ingresar al sitio de administración

Ahora, intente iniciar sesión con la cuenta de superusuario que creó en el paso anterior. Debería ver la página de índice del administrador de Django:

Debería ver algunos tipos de contenido editable: grupos y usuarios. Son proporcionados por django.contrib.auth, el marco de autenticación que viene con Django.

Hacer que la aplicación de sondeo sea modificable en el administrador

Pero, ¿dónde está nuestra aplicación de sondeo? No se muestra en la página de índice del administrador.

Solo queda una cosa por hacer: tenemos que decirle al administrador que los objetos Question tienen una interfaz de administración. Para hacer esto, abra el archivo polls/admin.py y edítelo para que se vea así:

from django.contrib import admin

from.models import Question

admin.site.register(Question)

Explorar la funcionalidad de administración gratuita

Ahora que hemos registrado Question, Django sabe que debe mostrarse en la página de índice del administrador:

Haga clic en "Preguntas". Ahora estás en la página de "lista de cambios" para las preguntas. Esta página muestra todas las preguntas en la base de datos y te permite elegir una para cambiarla. Allí está la pregunta "¿Qué pasa?" que creamos anteriormente:

Haga clic en la pregunta "¿Qué pasa?" para editarla:

Cosas que hay que notar aquí:

• El formulario se genera automáticamente a partir del modelo Question.
• Los diferentes tipos de campos de modelo (~django.db.models.DateTimeField, ~django.db.models.CharField) corresponden al widget de entrada HTML adecuado. Cada tipo de campo sabe cómo mostrarse en el administrador de Django.
• Cada ~django.db.models.DateTimeField obtiene atajos de JavaScript gratuitos. Las fechas obtienen un atajo "Hoy" y un desplegable de calendario, y las horas obtienen un atajo "Ahora" y un desplegable conveniente que lista las horas comúnmente ingresadas.

La parte inferior de la página te da un par de opciones:

• Guardar -- Guarda los cambios y regresa a la página de lista de cambios para este tipo de objeto.
• Guardar y continuar editando -- Guarda los cambios y recarga la página de administrador para este objeto.
• Guardar y agregar otro -- Guarda los cambios y carga un nuevo formulario en blanco para este tipo de objeto.
• Eliminar -- Muestra una página de confirmación de eliminación.

Si el valor de "Fecha publicada" no coincide con la hora en que creó la pregunta en Creación de una Aplicación Básica de Sondeo, probablemente significa que olvidó establecer el valor correcto para la configuración TIME_ZONE. Cambielo, recargue la página y verifique que aparezca el valor correcto.

Cambie la "Fecha publicada" haciendo clic en los atajos "Hoy" y "Ahora". Luego haga clic en "Guardar y continuar editando". Luego haga clic en "Historial" en la esquina superior derecha. Verá una página que lista todos los cambios realizados a este objeto a través del administrador de Django, con la marca de tiempo y el nombre de usuario de la persona que hizo el cambio:

Cuando esté cómodo con la API de modelos y se haya familiarizado con el sitio de administración, lea Creando las Vistas de la Interfaz Pública para aprender cómo agregar más vistas a nuestra aplicación de sondeos.

Resumen

¡Felicidades! Has completado el laboratorio Configurar la Base de Datos. Puedes practicar más laboratorios en LabEx para mejorar tus habilidades.