Hvad hvis du kunne organisere dine databaseobjekter (f.eks. tabeller og visninger) i navnerum i henhold til dets roller i systemet?
I denne artikel vil vi se den rigtige måde at håndtere PostgreSQL-skemaer i Django på og nogle små tips om Django-modeller og Python.

Skema

Også kendt som et navneområde er skema en type databaseobjekt, hvis formål er at være et hierarkisk organisationslag, der er lige under en database.
På PostgreSQL er "public" standardskemaet, men du kan oprette dit eget navnerum til at organisere andre slags objekter såsom tabeller, visninger, funktioner osv.

Databaseobjekthierarki

- Server |- PostgreSQL-instans (Port 5432 som standard) |- Rolle (brugere og grupper) |- Tablespace |- Database |- Trigger |- Udvidelse |- Sprog |- Skema |- Tabel |- Vis |- Materialiseret Vis |- Sekvens |- Funktion |- Fremgangsmåde

Om vores Lab

Det er et simpelt laboratorium med Django i et virtuelt miljø (med virtualenv) og PostgreSQL installeret i localhost.

Python 3.8
Django 3.0
PostgreSQL 12

Bør fungere med mange ældre versioner 🙂

Koder

> SQL (psql);
$ shell (Linux, FreeBSD, Unix*);
>>> Python-skal.

Øv

PostgreSQL

Databasestrukturen er det første, vi vil gøre.

Oprettelse af databasebruger til applikationen;
Oprettelse af database;
Skemaoprettelse;
Tabeloprettelse

Lad os skabe vores eget eksempel i psql indbygget kommandolinjeværktøj:

$ psql

Oprettelse af brugerapplikation:

OPRET ROLLE user_test KRYPTET PASSWORD '123' LOGIN;

Databaserollen blev oprettet med en krypteret adgangskode og login-attribut (bruger).

Oprettelse af database til test:

> OPRET DATABASE db_test OWNER user_test;

Databasen ejes af "user_test".

Opret forbindelse til den som bruger "user_test":

> \c db_test user_test

Inde i psql shell \c database brugernavn.

Oprettelse af et skema:

> OPRET SKEMA ns_hr;

Navnerummet til vores eksempel er klar!

Vis alle skemaer, der ikke er kataloger:

> SELECTnspname AS namespaceFROM pg_catalog.pg_namespaceWHERE nspname !~ '(^pg_|informationsskema)';

Output:

navneområde ----------- offentlig ns_hr

Bemærk, at standardnavneområdet (offentligt) og ns_hr vises, oprettet til vores laboratorium.

Oprettelse af en tabel i ns_hr-skema:

> OPRET TABEL ns_hr.tb_person( id_ seriel primær nøgle, navnetekst ikke null, efternavnstekst ikke null);

Et simpelt bord...

Tryk på <Ctrl> + D for at afslutte.

Django

Det er tid til at kode i Python! 😀

Virtuelt miljø;
Installation af Python-moduler;
Django-projektoprettelse og -konfiguration;
Oprettelse af Django-app;
Django-modeloprettelse;
Migreringer;
Test i skal;

Oprettelse af virtuelt miljø:

$ virtualenv -p `which python3.8` django

Den absolutte sti for binær i Python 3.8 blev angivet som Python-fortolker af dette miljø.

Få adgang til biblioteket over miljøet og aktiver det:

$ cd django &&source bin/activate

Din prompt blev ændret, startede ved "(django)", hvilket indikerer, at dit virtuelle miljø var aktiveret.

Installer behovsmoduler til vores test:

$ pip installer django psycopg2-binær configobj ipython

Henholdsvis:Django-webframework, PostgreSQL-driver, konfigurationsfillæser og forbedret interaktiv shell.

Oprettelse af nyt Django-projekt:

$ django-admin startproject my_project

Omdøb biblioteket for projektet til src:

$ mv my_project src

Dette er for at lette kataloghierarkiet og vil ikke påvirke resultaterne. Det er fordi det har en mappe med samme navn, der kan forårsage en vis forvirring...

Oprettelse af databasekonfigurationsfil:

$ kat < src/my_project/db.confDB_HOST ='localhost'DB_NAME ='db_test'DB_USER ='user_test'DB_PASSWORD ='123'DB_PORT =5432EOF

Her oprettede vi en separat konfigurationsfil til databaseforbindelsen.

Rediger hovedkonfigurationsfilen for projektet:

$ vim src/my_project/settings.py

importer os fra configobj importer ConfigObj

Tilføj en linje under importen, der bringer ConfigObj-klassen.

# Database# https://docs.djangoproject.com/en/2.2/ref/settings/#databases# Databasekonfigurationsfil placeringDB_CONF_FILE =f'{BASE_DIR}/my_project/db.conf'# Læs konfigurationerne fra fileDB_CONFIG =ConfigObj(DB_CONF_FILE)# DatabaseforbindelsesparametreDB_HOST =DB_CONFIG['DB_HOST']DB_NAME =DB_CONFIG['DB_NAME']DB_USER =DB_CONFIG['DB_USER']DB_PASSWORD =DB_CONFIG ='DB_CONFIG ='DB_DBASE_PASSFIG' { 'default':{ 'ENGINE':'django.db.backends.postgresql', 'NAME':DB_NAME, 'USER':DB_USER, 'PASSWORD':DB_PASSWORD, 'HOST':DB_HOST, 'PORT':DB_PORT, } }

Rediger databasens "session" som ovenfor.

Symbolisk linkoprettelse til manage.py:

$ ln -s `pwd`/src/manage.py `pwd`/bin/manage.py

For at lette vores arbejde har vi oprettet et symbolsk link til manage.py i bin-biblioteket, der er i vores $PATH.

Kør virtuel webserver:

$ manage.py runserver 0.0.0.0:8000

Test i din browser:http://localhost:8000 og derefter + C for at afbryde.

Få adgang til projektmappe:

$ cd src

Lad os tjekke filerne i den aktuelle mappe:

$-træ .

Output:

.├── manage.py└── my_project ├── db.conf ├── __init__.py ├── __pycache__ │ ├── pyinit │c ├c .pyc │ ├── urls.cpython-38.pyc │ └── wsgi.cpython-38.pyc ├── settings.py ├── urls.py ─>─ 
 List indholdet af den aktuelle mappe i et træ-lignende format.
Her ser vi alle filer inde i projektet.
 
 
 
 Første migrering for Django-metadata: 
 $ manage.py migrere
 
 
 
 Oprettelse af superbruger af Django: 
 $ manage.py createsuperuser
 
 
 
 Opret en app: 
 $ manage.py startapp human_resource
 
 
 
 Rediger settings.py for at tilføje ny app: 
 $ vim my_project/settings.py
 # Application definitionINSTALLED_APPS =[ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django .contrib.staticfiles', # Custom Apps 'human_resource',]
 
 Et fedt Django-trick:du kan bruge en mappe modeller i stedet for en fil models.py.
Men du skal oprette en dunder init-fil (__init__.py) inde i modelbiblioteket.
Lad os gå!
 
 
 
 Oprettelse af modelbibliotek inde i app-biblioteket: 
 $ mkdir human_resource/models
 
 
 
 Fjern models.py-filen: 
 $ rm -f human_resource/models.py
 
 
 
 Oprettelse af model: 
 $ vim human_resource/models/hr.py
 fra django.db.models import AutoField fra django.db.models import Model fra django.db.models import TextFieldclass Person(Model):''' Person Model Navneområde:ns_hr Tabel:tb_person ''' id_ =AutoField(db_column='id_', name='id', primary_key=True,) name =TextField(db_column='name', name='name',) surname =TextField(db_column='efternavn', navn='efternavn',) def __str__(self):return f'{self.name} {self.surname}' class Meta:db_table ='ns_hr"."tb_person' # 'schema"."object' verbose_name_plural ='Person'
 
 For at nyde fordelene ved PostgreSQL-skemaer, inde i din model, i Meta indre klasse, til værdien af "db_table" attribut, skal du sætte en prik, der adskiller navneområde og objekt mellem anførselstegn.
 
 'schema"."object' 
 
 Objektet kunne være en tabel eller en visning, for eksempel...
 
 
 
 Dunder init inde i modelbiblioteket for at migreringerne træder i kraft: 
 vim human_resource/models/__init__.py
 fra human_resource.models.hr import person
 
 Dette er nødvendigt for modelbiblioteket fungerer som models.py-fil.
 
 
 (Nej) Migrationer:Min database, mine regler!
 
 Vi skaber strukturen i vores database, og ingen ORM bør gøre det for os!
Vi har magten!
Vi har magten!
Vi har kommandoen!
 
 Vores database, vores regler! 😉
 
 Bare modeller din database med dine egne hænder og lav en falsk Django-migrering.
For det er kun vi, der ved, hvordan databaseobjekterne skal oprettes 😉
 
 
 
 Foretag migreringer til human_resource-appen: 
 $ manage.py makemigrations human_resource
 
 
 
 Falsk migrering: 
 $ manage.py migrate --fake
 
 
 
 Lad os tjekke mappehierarkiet i appen: 
 $ træ human_resource/
 human_resource/├── admin.py├── apps.py├── __init__.py├── migrations│ ├── 0001_initial.py│ ├│ ├│che ├│che 0001_initial.cpython-38.pyc│ └── __init__.cpython-38.pyc├── models│ ├── hr.py│ ├──└└ __init __.py│ .pyc- py
 
 
 
 Django Shell (Ipython): 
 $ manage.py shell
 >>> fra human_resource.models.hr import Person>>> p =Person(navn='Ludwig', efternavn='van Beethoven')>>> print(p)
 
 Output:
 Ludwig van Beethoven
 >>> p.save() # Vedvarer i databasen
 
 Tryk på <Ctrl> + D for at afslutte!
 
 
 
 Databaseshell (psql): 
 $ manage.py dbshell
 
 En forespørgsel for at kontrollere, om dataene blev indsat af Django:
 > VÆLG id_, navn, efternavn FRA ns_hr.tb_person;
 
 Output:
  id | navn | efternavn ----+--------+--------------- 1 | Ludwig | van Beethoven
 
 
 Konklusion
 
 PostgreSQL er et robust og kraftfuldt RDBMS med en masse funktioner, inklusive navnerum til dets objekter.
Django er en fantastisk webramme, der er meget robust og også har en masse funktioner.
Så du kan udtrække det bedste af begge for at opnå bedre resultater, og for at gøre dette er en af måderne at få en bedre organisation.
At organisere dine databaseobjekter i navnerum i overensstemmelse med dets roller vil give fordele for dig 😉

PostgreSQL-skemaer / navnerum med Django

Skema

Databaseobjekthierarki

Om vores Lab

Øv

PostgreSQL

Django

(Nej) Migrationer:Min database, mine regler!

Konklusion