Come Creare Modelli Django

Introduzione

Nel tutorial precedente, “Come creare un’app Django e collegarla a un database,” abbiamo coperto come creare un database MySQL, come creare e avviare un’applicazione Django e come collegarla a un database MySQL.

In questo tutorial, creeremo i modelli Django che definiscono i campi e i comportamenti dei dati dell’applicazione Blog che memorizzeremo. Questi modelli mappano i dati dalla tua applicazione Django al database. È ciò che Django utilizza per generare le tabelle del database tramite la loro API di mapping oggetto-relazionale (ORM), chiamata “modelli.”

Prerequisiti

Questo tutorial fa parte della serie sullo sviluppo di Django e ne è il proseguimento.

Se non hai seguito questa serie, facciamo le seguenti ipotesi:

• Hai installato Django versione 4 o superiore.
• Hai collegato la tua app Django a un database. Stiamo utilizzando MySQL, e puoi ottenere questa connessione seguendo la seconda parte della serie Django, “Come Creare un’App Django e Collegarla a un Database“.
• Stai lavorando con un sistema operativo basato su Unix, preferibilmente un server cloud Ubuntu 22.04, poiché è il sistema su cui abbiamo testato. Se desideri configurare Django su un ambiente simile, consulta il nostro tutorial, “Come Installare Django e Configurare un Ambiente di Sviluppo su Ubuntu 22.04“.

Poiché questo tutorial tratta principalmente dei modelli Django, potresti seguirlo anche se hai una configurazione leggermente diversa.

Passo 1 — Crea App Django

Per essere coerenti con la filosofia modulare di Django, creeremo un’app Django all’interno del nostro progetto che contiene tutti i file necessari per creare il sito web del blog.

Ogni volta che iniziamo a lavorare in Python e Django, dovremmo attivare il nostro ambiente virtuale Python e spostarci nella directory principale della nostra app. Se hai seguito la serie, puoi farlo digitando il seguente comando.

cd ~/my_blog_app
. env/bin/activate
cd blog

Da qui, eseguiamo questo comando:

python manage.py startapp blogsite

Questo creerà la nostra app insieme a una directory blogsite.

A questo punto della serie di tutorial, avrai la seguente struttura di directory per il tuo progetto:

my_blog_app/
└── blog
    ├── blog
    │   ├── __init__.py
    │   ├── __pycache__
    │   │   ├── __init__.cpython-38.pyc
    │   │   ├── settings.cpython-38.pyc
    │   │   ├── urls.cpython-38.pyc
    │   │   └── wsgi.cpython-38.pyc
    │   ├── asgi.py
    │   ├── settings.py
    │   ├── urls.py
    │   └── wsgi.py
    ├── blogsite
    │   ├── __init__.py
    │   ├── admin.py
    │   ├── apps.py
    │   ├── migrations
    │   │   └── __init__.py
    │   ├── models.py
    │   ├── tests.py
    │   └── views.py
    └── manage.py

Il file su cui ci concentreremo per questo tutorial sarà il file models.py, che si trova nella directory blogsite.

Passo 2 — Aggiungi il Modello dei Post

Prima di tutto dobbiamo aprire e modificare il file models.py in modo che contenga il codice per generare un modello Post. Un modello Post contiene i seguenti campi del database:

• title — Il titolo del post del blog.
• slug — Dove vengono memorizzati e generati gli URL validi per le pagine web.
• content — Il contenuto testuale del post del blog.
• created_on — La data in cui è stato creato il post.
• author — La persona che ha scritto il post.

Adesso, spostati nella directory in cui è contenuto il file models.py.

cd ~/my_blog_app/blog/blogsite

Usa il comando cat per mostrare i contenuti del file nel tuo terminale.

cat models.py

Il file dovrebbe avere il seguente codice, che importa i modelli, insieme a un commento che descrive cosa deve essere inserito in questo file models.py.

from django.db import models

# Crea i tuoi modelli qui.

Utilizzando il tuo editor di testo preferito, aggiungi il seguente codice al file models.py. Utilizzeremo nano come editor di testo, ma sei libero di utilizzare quello che preferisci.

nano models.py

All’interno di questo file, il codice per importare l’API dei modelli è già aggiunto, possiamo procedere eliminando il commento che segue. Poi importeremo slugify per generare gli slug dalle stringhe, il User di Django per l’autenticazione, e reverse da django.urls per darci una maggiore flessibilità nella creazione degli URL.

from django.db import models
from django.template.defaultfilters import slugify
from django.contrib.auth.models import User
from django.urls import reverse

Successivamente, aggiungi il metodo di classe sulla classe del modello che chiameremo Post, con i seguenti campi del database, title, slug, content, created_on e author. Aggiungili sotto le tue dichiarazioni di importazione.

...
class Post(models.Model):
    title = models.CharField(max_length=255)
    slug = models.SlugField(unique=True, max_length=255)
    content = models.TextField()
    created_on = models.DateTimeField(auto_now_add=True)
    author = models.TextField()

Successivamente, aggiungeremo la funzionalità per la generazione dell’URL e la funzione per salvare il post. Questo è cruciale, perché crea un link unico per corrispondere al nostro post unico.

...
    def get_absolute_url(self):
        return reverse('blog_post_detail', args=[self.slug])

    def save(self, *args, **kwargs):
        if not self.slug:
            self.slug = slugify(self.title)
        super(Post, self).save(*args, **kwargs)

Ora dobbiamo dire al modello come devono essere ordinati i post e visualizzati sulla pagina web. La logica per questo sarà aggiunta a una classe Meta interna annidata. La classe Meta contiene generalmente altre importanti logiche del modello che non sono relative alla definizione dei campi del database.

...
    class Meta:
        ordering = ['created_on']

        def __unicode__(self):
            return self.title

Infine, aggiungeremo il modello Comment a questo file. Questo comporta l’aggiunta di un’altra classe chiamata Comment con models.Models nella sua firma e i seguenti campi del database definiti:

• name — Il nome della persona che pubblica il commento.
• email — L’indirizzo email della persona che ha pubblicato il commento.
• text — Il testo del commento stesso.
• post — Il post con cui è stato fatto il commento.
• created_on — L’orario in cui il commento è stato creato.

...
class Comment(models.Model):
    name = models.CharField(max_length=42)
    email = models.EmailField(max_length=75)
    website = models.URLField(max_length=200, null=True, blank=True)
    content = models.TextField()
    post = models.ForeignKey(Post, on_delete=models.CASCADE)
    created_on = models.DateTimeField(auto_now_add=True)

A questo punto models.py sarà completo. Assicurati che il tuo file models.py corrisponda al seguente:

from django.db import models
from django.template.defaultfilters import slugify
from django.contrib.auth.models import User
from django.urls import reverse


class Post(models.Model):
    title = models.CharField(max_length=255)
    slug = models.SlugField(unique=True, max_length=255)
    content = models.TextField()
    created_on = models.DateTimeField(auto_now_add=True)
    author = models.TextField()

    def get_absolute_url(self):
        return reverse('blog_post_detail', args=[self.slug])
    
    def save(self, *args, **kwargs):
        if not self.slug:
            self.slug = slugify(self.title)
        super(Post, self).save(*args, **kwargs)

    class Meta:
        ordering = ['created_on']

        def __unicode__(self):
            return self.title


class Comment(models.Model):
    name = models.CharField(max_length=42)
    email = models.EmailField(max_length=75)
    website = models.URLField(max_length=200, null=True, blank=True)
    content = models.TextField()
    post = models.ForeignKey(Post, on_delete=models.CASCADE)
    created_on = models.DateTimeField(auto_now_add=True)

Assicurati di salvare e chiudere il file. Se stai usando nano, puoi farlo digitando CTRL e X, poi Y, poi ENTER.

Con il file models.py configurato, possiamo passare all’aggiornamento del nostro file settings.py.

Passaggio 3 — Aggiornare le impostazioni

Ora che abbiamo aggiunto i modelli alla nostra applicazione, dobbiamo informare il nostro progetto dell’esistenza dell’applicazione blogsite che abbiamo appena aggiunto. Facciamo questo aggiungendola alla sezione INSTALLED_APPS in settings.py.

Naviga nella directory in cui si trova il tuo file settings.py.

cd ~/my_blog_app/blog/blog

Da qui, apri il tuo file settings.py, ad esempio con nano.

 nano settings.py

Con il file aperto, aggiungi la tua app blogsite alla sezione INSTALLED_APPS del file, come indicato di seguito.

# Definizione dell'applicazione
INSTALLED_APPS = [
    'blogsite',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

Con l’applicazione blogsite aggiunta, puoi salvare ed uscire dal file.

A questo punto, siamo pronti per procedere ad applicare queste modifiche.

Passaggio 4 — Esegui le migrazioni

Con i nostri modelli Post e Comment aggiunti, il passo successivo è applicare queste modifiche in modo che lo schema del nostro database MySQL le riconosca e crei le tabelle necessarie.

Prima di tutto, dobbiamo raggruppare le modifiche del nostro modello in file di migrazione individuali utilizzando il comando makemigrations. Questi file sono simili a quelli dei commit in un sistema di controllo versione come Git.

Ora, se navighi su ~/my_blog_app/blog/blogsite/migrations e esegui ls, noterai che c’è solo un file __init__.py. Questo cambierà una volta aggiunte le migrazioni.

Cambia alla directory del blog usando cd, così:

cd ~/my_blog_app/blog

Poi esegui il comando makemigrations su manage.py.

python manage.py makemigrations

Dovresti ricevere quindi il seguente output nella tua finestra terminale:

Output
Migrations for 'blogsite':
  blogsite/migrations/0001_initial.py
    - Create model Post
    - Create model Comment

Ricorda, quando abbiamo navigato fino a /~/my_blog_app/blog/blogsite/migrations e c’era solo il file __init__.py? Se ora torniamo a quella directory noteremo che sono stati aggiunti due elementi: __pycache__ e 0001_initial.py. Il file 0001_initial.py è stato generato automaticamente quando hai eseguito makemigrations. Un file simile verrà generato ogni volta che esegui makemigrations.

Esegui less 0001_initial.py dalla directory in cui si trova se vuoi leggere cosa contiene il file.

Ora naviga fino a ~/my_blog_app/blog:

cd ~/my_blog_app/blog

Dato che abbiamo creato un file di migrazione, dobbiamo applicare le modifiche descritte da questi file al database usando il comando migrate. Ma prima controlliamo quali migrazioni esistono attualmente, usando il comando showmigrations.

python manage.py showmigrations

Output
admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
 [X] 0003_logentry_add_action_flag_choices
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
 [X] 0009_alter_user_last_name_max_length
 [X] 0010_alter_group_name_max_length
 [X] 0011_update_proxy_permissions
blogsite
 [ ] 0001_initial
contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name
sessions
 [X] 0001_initial

Noterai che tutte le migrazioni sono controllate tranne quella per 0001_initial che abbiamo appena creato con i modelli Post e Comment.

Adesso controlliamo quali dichiarazioni SQL verranno eseguite una volta che eseguiamo le migrazioni, usando il seguente comando. Prende come argomento la migrazione e il titolo della migrazione:

python manage.py sqlmigrate blogsite 0001_initial

Di seguito viene rivelata la query SQL effettiva che viene eseguita dietro le quinte.

Output
--
-- Crea il modello Post
--
CREATE TABLE `blogsite_post` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `title` varchar(255) NOT NULL, `slug` varchar(255) NOT NULL UNIQUE, `content` longtext NOT NULL, `created_on` datetime(6) NOT NULL, `author` longtext NOT NULL);
--
-- Crea il modello Comment
--
CREATE TABLE `blogsite_comment` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `name` varchar(42) NOT NULL, `email` varchar(75) NOT NULL, `website` varchar(200) NULL, `content` longtext NOT NULL, `created_on` datetime(6) NOT NULL, `post_id` integer NOT NULL);
ALTER TABLE `blogsite_comment` ADD CONSTRAINT `blogsite_comment_post_id_de248bfe_fk_blogsite_post_id` FOREIGN KEY (`post_id`) REFERENCES `blogsite_post` (`id`);

Adesso eseguiamo le migrazioni in modo che vengano applicate al nostro database MySQL.

python manage.py migrate

Riceveremo il seguente output:

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

Hai ora applicato con successo le tue migrazioni.

È importante tenere presente che ci sono tre avvertenze per le migrazioni di Django con MySQL come backend, come indicato nella documentazione di Django.

• Mancanza di supporto per le transazioni intorno alle operazioni di modifica dello schema. In altre parole, se una migrazione non riesce ad applicarsi correttamente, dovrai annullare manualmente le modifiche apportate per tentare un’altra migrazione. Non è possibile tornare indietro, a un punto precedente, prima che siano state apportate modifiche nella migrazione fallita.
• Per la maggior parte delle operazioni di modifica dello schema, MySQL riscriverà completamente le tabelle. Nel peggiore dei casi, la complessità temporale sarà proporzionale al numero di righe nella tabella per aggiungere o rimuovere colonne. Secondo la documentazione di Django, ciò potrebbe richiedere fino a un minuto per un milione di righe.
• In MySQL, ci sono dei limiti sulle lunghezze dei nomi per colonne, tabelle e indici. C’è anche un limite sulla dimensione combinata di tutte le colonne e delle coperture degli indici. Mentre alcuni altri backend possono supportare limiti più alti creati in Django, gli stessi indici non riusciranno a essere creati con un backend MySQL.

Per ogni database che consideri per l’uso con Django, assicurati di valutare i vantaggi e gli svantaggi di ciascuno.

Passaggio 5 – Verifica lo schema del database

Con le migrazioni complete, dovremmo verificare la corretta generazione delle tabelle MySQL che abbiamo creato tramite i nostri modelli Django.

Per fare ciò, esegui il seguente comando nel terminale per accedere a MySQL. Utilizzeremo l’utente djangouser che abbiamo creato nel precedente tutorial.

mysql blog_data -u djangouser

Ora, seleziona il nostro database blog_data. Se non sai quale database stai utilizzando, puoi mostrare tutti i database con SHOW DATABASES; in SQL.

USE blog_data;

Quindi digita il seguente comando per visualizzare le tabelle.

SHOW TABLES;

Questa query SQL dovrebbe rivelare quanto segue:

Output
+----------------------------+
| Tables_in_blog_data        |
+----------------------------+
| auth_group                 |
| auth_group_permissions     |
| auth_permission            |
| auth_user                  |
| auth_user_groups           |
| auth_user_user_permissions |
| blogsite_comment           |
| blogsite_post              |
| django_admin_log           |
| django_content_type        |
| django_migrations          |
| django_session             |
+----------------------------+
12 rows in set (0.01 sec)

Tra le tabelle ci sono blogsite_comment e blogsite_post. Questi sono i modelli che abbiamo appena creato. Verifichiamo che contengano i campi che abbiamo definito.

DESCRIBE blogsite_comment;

Output
+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| id         | int          | NO   | PRI | NULL    | auto_increment |
| name       | varchar(42)  | NO   |     | NULL    |                |
| email      | varchar(75)  | NO   |     | NULL    |                |
| website    | varchar(200) | YES  |     | NULL    |                |
| content    | longtext     | NO   |     | NULL    |                |
| created_on | datetime(6)  | NO   |     | NULL    |                |
| post_id    | int          | NO   | MUL | NULL    |                |
+------------+--------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)

DESCRIBE blogsite_post;

Output
+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| id         | int          | NO   | PRI | NULL    | auto_increment |
| title      | varchar(255) | NO   |     | NULL    |                |
| slug       | varchar(255) | NO   | UNI | NULL    |                |
| content    | longtext     | NO   |     | NULL    |                |
| created_on | datetime(6)  | NO   |     | NULL    |                |
| author     | longtext     | NO   |     | NULL    |                |
+------------+--------------+------+-----+---------+----------------+
6 rows in set (0.00 sec)

Abbiamo verificato che le tabelle del database siano state generate con successo dalle migrazioni del nostro modello Django.

Puoi uscire da MySQL con CTRL + D e quando sei pronto per lasciare il tuo ambiente Python, puoi eseguire il comando deactivate:

deactivate

Disattivare il tuo ambiente di programmazione ti riporterà al prompt dei comandi del terminale.

Conclusion

In questo tutorial, abbiamo aggiunto con successo modelli per la funzionalità di base in un’applicazione web di blog. Hai imparato come codificare modelli, come funzionano le migrazioni e il processo di traduzione dei modelli Django in effettive tabelle del database MySQL.