Sådan bruges Django med MongoDB ved kun at tilføje en linje kode.

Sådan bruges Django med MongoDB ved kun at tilføje en linje kode.

Hvis du vil bruge MongoDB som din backend-database i dit Django-projekt, skal du blot tilføje denne ene linje til din settings.py-fil:

DATABASES = { ‘default’: { ‘ENGINE’: ‘djongo’, ‘NAME’: ‘your-db-name’, }}

Det er så simpelt!

Dernæst skal du logge ind på dit admin-hjem (localhost: 8000 / admin /) og begynde at tilføje "indlejrede dokumenter" til MongoDB ved hjælp af Admin GUI:

I oktober 2017 sluttede MongoDB det sidste trin i offentliggørelse, prissatte sin børsintroduktion til $ 24 og hævede $ 192 millioner i processen. Virksomhedens økonomi er vokset støt:

MongoDB leverer open source-databasesoftware. Dette er meget nyttigt for startups i tidlige faser, der ønsker at starte, mens de er begrænset af stramme budgetter. En gennemgang af Googles søgetendenser for MongoDB afslørede en konstant stigning i interessen.

MongoDB er i stigende grad blevet en populær databasesoftware at arbejde med. Databaser og databasesystemer (DBMS) har eksisteret i mere end fem årtier. De opstod i begyndelsen af ​​1960'erne, og den mest populære smag var det relationelle databasesystem.

Men MongoDB går rundt og kalder sig selv et "ikke-relationelt" databasesystem og har fremsat høje krav om sin tilgang til lagring af data. Så hvad er egentlig BIG-aftalen her?

MongoDB vs SQL

Næsten stort set alle relationsdatabasesystemer bruger Structured Query Language (SQL) (eller en tweaked version af det) til at kommunikere med datahåndteringssoftwaren. Flere universitetskurser er udelukkende dedikeret til forståelse og beherskelse af SQL-syntaksen.

SQL var blevet det de facto sprog til at arbejde med enhver database (DB) software, proprietær eller open source. Derefter kom MongoDB sammen og besluttede at vise fuldstændig tilsidesættelse af dette gamle magtens sprog og introducerede sin egen forespørgsel.

Sproget er det Mordor, som jeg ikke vil tale her. På den almindelige tunge står der: ”En ring til at herske over dem alle. Én ring for at finde dem. Én ring for at bringe dem alle sammen og i mørket binde dem. ”- Gandalf ( fra Ringenes herre )

MongoDB Schemaless vs SQL Schema: I en SQL-database er det umuligt at tilføje data, før du definerer tabeller og felttyper i det, der kaldes et skema. I en MongoDB-database kan data tilføjes hvor som helst og når som helst. Der er ikke behov for at specificere et dokumentdesign eller endda en samling foran.

MongoDB-dokumenter vs SQL-tabeller: SQL-databaser giver en butik med relaterede datatabeller. Hver række er en anden rekord. Designet er stift: du kan ikke bruge den samme tabel til at gemme forskellige oplysninger eller indsætte en streng, hvor et tal forventes.

MongoDB-databasen gemmer JSON-lignende feltværdipar-dokumenter. Lignende dokumenter kan gemmes i en samling, der er analog med en SQL-tabel. Du kan dog gemme de data, du kan lide, i ethvert dokument - MongoDB klager ikke. SQL-tabeller opretter en streng dataskabelon, så det er svært at lave fejl. MongoDB er mere fleksibel og tilgivende, men at være i stand til at gemme data overalt kan føre til konsistensproblemer.

Der er en overflod af onlineindhold til rådighed, der hævder, at MongoDB ikke er et supersæt af SQL. Programmer, der kører på SQL, kan ikke overføres til MongoDB. Jeg går ud på en lem her for at hævde, at MongoDB i forbindelse med Django er et supersæt af SQL .

Så hvorfor eksisterer den populære tro, at MongoDB ikke er et supersæt af SQL, til at begynde med?

MongoDB kræver denormalisering af data: I MongoDb er der ingen JOIN-support. Dette betyder, at vi bliver nødt til at denormalisere vores dokumenter. Denormaliserede dokumenter fører til hurtigere forespørgsler, men opdatering af dokumentfeltoplysningerne i flere denormaliserede dokumenter vil være betydeligt langsommere.

Der er ingen JOIN'er : SQL-forespørgsler tilbyder en kraftig JOIN-klausul. Vi kan få relaterede data i flere tabeller ved hjælp af en enkelt SQL-sætning. I ikke-relationelle databaser som MongoDB er der ingen JOIN'er, som der ville være i relationsdatabaser. Dette betyder, at du skal udføre flere forespørgsler og sammenføje dataene manuelt i din kode.

Ingen transaktioner: I SQL-databaser kan to eller flere opdateringer udføres i en transaktion - en alt-eller-intet indpakning, der garanterer succes eller fiasko. Hvis vi udfører to opdateringer individuelt, kan den ene lykkes, og den anden mislykkes - og dermed lader vores tal være ude af synkronisering. Placering af de samme opdateringer i en transaktion sikrer, at begge lykkes eller begge mislykkes.

Ingen begrænsninger for udenlandske nøgler: De fleste SQL-databaser giver dig mulighed for at håndhæve regler for dataintegritet ved hjælp af begrænsninger for udenlandske nøgler. Dette sikrer, at alle rækker har en gyldig fremmed nøgle til kode, der matcher en post i tilslutningstabellen, og sørger for, at en post fra tilslutningstabellen ikke fjernes, hvis en eller flere rækker stadig henviser til dem.

Skemaet håndhæver disse regler, som databasen skal følge. Det er umuligt for udviklere eller brugere at tilføje, redigere eller fjerne poster, hvilket kan resultere i ugyldige data eller forældreløse poster. De samme indstillinger for dataintegritet er ikke tilgængelige i MongoDB. Du kan gemme, hvad du vil, uanset andre dokumenter. Ideelt set ville et enkelt dokument være den eneste kilde til al information om en vare.

Behovet for en databasemodel

Objekter er Pythons abstraktion for data. Alle data i et Python-program er repræsenteret af objekter eller af forholdet mellem objekter. Mens objekter er en god måde at repræsentere data på, opstår der et problem, når vi vil gøre dataene vedvarende. Mængden af ​​data kan være enorm, og de skal hentes fra den vedvarende hukommelse hurtigt og effektivt. Denne databasesoftware skal bruges til at gemme objekterne. En mulig databasesoftware er en relationel, SQL-baseret databasesoftware.

En objektrelationskortlægger (ORM) er et kodebibliotek, der automatiserer overførslen af ​​data, der er gemt i relationsdatabasetabeller til Python-objekter, der bruges i Python-kode. ORM'er giver en abstraktion på højt niveau i en relationsdatabase, der giver en udvikler mulighed for at skrive Python-kode i stedet for SQL-syntaks for at oprette, læse, opdatere og slette data og skemaer i deres database. Udviklere kan bruge det Python-programmeringssprog, som de er fortrolige med, i stedet for at skrive SQL-sætninger eller lagrede procedurer.

Et eksempel på en ORM-ramme for Python er SQLAlchemy. SQLAlchemy ORM præsenterer en metode til at forbinde brugerdefinerede Python-klasser med databasetabeller og forekomster af disse klasser (objekter) med rækker i deres tilsvarende tabeller. Det inkluderer et system, der synkroniserer alle ændringer i tilstand mellem objekter og deres relaterede rækker. Webrammer som kolbe bruger SQLAlchemy til vedvarende lagring af data.

Django ORM: Django kommer med sin egen ORM eller model for kort.Modellen er den eneste, endelige kilde til information om dine data. Den indeholder de væsentlige felter og opførsel af de data, du lagrer. Generelt kortlægges hver model til en enkelt databasetabel. Django-modellen gør det også muligt at skifte mellem forskellige relationsdatabaser som Oracle SQL, MySQL eller MSSQL.

Brug af Django ORM til at tilføje dokumenter til MongoDB

Lad os sige, at du vil oprette en blogplatform ved hjælp af Django med MongoDB som din backend.

app/models.pyDefinér BlogContentmodellen i din blogfil :

from djongo import modelsfrom djongo.models import forms
class BlogContent(models.Model): comment = models.CharField(max_length=100) author = models.CharField(max_length=100) class Meta: abstract = True

For at få adgang til modellen ved hjælp af Django Admin skal du bruge en formdefinition til ovenstående model. Definer det som vist nedenfor:

class BlogContentForm(forms.ModelForm): class Meta: model = BlogContent fields = ( 'comment', 'author' )

Nu "integrere" din BlogContentinderside en BlogPostved hjælp af EmbeddedModelFieldnedenstående:

class BlogPost(models.Model): h1 = models.CharField(max_length=100) content = models.EmbeddedModelField( model_container=BlogContent, model_form=BlogContentForm ) 

Det er det, du er indstillet på! Tænd Django Admin på localhost: 8000 / admin / og det er hvad du får:

Antag derefter, at du vil "udvide" forfatterfeltet til at indeholde mere end bare navnet. Du har brug for både et navn og en e-mail. Lav blot forfatterfeltet til et "indlejret" felt i stedet for et "char" -felt:

class Author(models.Model): name = models.CharField(max_length=100) email = models.CharField(max_length=100) class Meta: abstract = Trueclass AuthorForm(forms.ModelForm): class Meta: model = Author fields = ( 'name', 'email' )
class BlogContent(models.Model): comment = models.CharField(max_length=100) author = models.EmbeddedModelField( model_container=Author, model_form=AuthorForm ) class Meta: abstract = True

Hvis et blogindlæg har flere indhold fra flere forfattere, skal du definere en ny model:

class MultipleBlogPosts(models.Model): h1 = models.CharField(max_length=100) content = models.ArrayModelField( model_container=BlogContent, model_form=BlogContentForm )

Tag Django Admin op med de nye ændringer, og du har:

Ways to integrate Django and MongoDB.

The Django ORM consists of multiple Abstraction Layers stacked on top of each other.

As a web developer, you can take up the challenge of connecting Django to MongoDB in two ways. Take a look at the Django framework stack above to guess the possible entry points.

Use a MongoDB compatible model

You can completely avoid using the “batteries included” Django models in your project. Instead, use a third party framework like MongoEngine or Ming in you Django projects.

Choosing a different Model means you miss out on:

  • 1500+ core contributors to the project
  • Hourly fixes and ticket resolution

You’d ramp down on the expertise of existing Django models and ramp up on the new model framework. But perhaps the biggest drawback is that your project can’t use any of Django’s contrib models! Forget about using Admin, Sessions, Users, Auth, and other contrib modules for your project.

Some of these disadvantages are offset by forking a new branch of Django itself. Django-nonrel is an independent branch of Django that adds NoSQL database support to Django. Django-nonrel allows for writing portable Django apps. However, the admin interface does not work fully. There is no active development taking place on the Django-nonrel project.

Django MongoDB Engine is another MongoDB backend for Django which is a fork off the MongoEngine ODM.

Django SQL to MongoDB transpiler — Djongo

Another approach is to translate Django SQL query syntax generated by the Django ORM into pymongo commands. Djongo is one such SQL to MongoDB query compiler. It translates every SQL query string into a mongoDB query document. As a result, all Django models and related modules work as is. With this approach, you gain on:

  • Reuse of Django Models: Django is a stable framework with continuous development and enhancements. The Django ORM is quite extensive and feature-rich. Defining a third party ORM to work with MongoDB means reproducing the entire Django ORM again. The new ORM needs to constantly align with the Django ORM. Several Django features will never make it into the third party ORM. The idea with Djongo is to reuse existing Django ORM features by finally translating SQL queries to MongoDB syntax.
  • SQL syntax will never change regardless of future additions to Django. By using Djongo, your project is now future proof!

Making Django work with MongoDB

Emulating Schema in MongoDB: While there is no schema support in MongoDB, this can be emulated. Djongo provides the schema support required in Django by using and defining a combination of MongoDB validator rules and by creating a __schema__ collection. The __schema__ collection stores information for supporting features like the SQL AUTOINCREMENT key.

JOIN support in MongoDB: In version 3.2, MongoDB introduced the $lookup operator. It performs a left outer join to a collection in the same database to filter in documents from the “joined” collection for processing. The $lookup stage does an equality match between a field from the input documents with a field from the documents of the “joined” collection.

To each input document, the $lookup stage adds a new array field whose elements are the matching documents from the “joined” collection. The $lookup stage passes these reshaped documents to the next stage.

Djongo uses the $lookup aggregation operator to perform all Django related JOIN queries. This is how it makes admin and other contrib modules work as is.

Transaction support in MongoDB: Despite the power of single-document atomic operations, there are cases that require multi-document transactions. When executing a transaction composed of sequential operations, certain issues arise, wherein if one operation fails, the previous operation within the transaction must “rollback” to the previous state — that is, the “all or nothing.”

For situations that require multi-document transactions, Djongo implements the two-phase commit pattern to provide support for these kinds of multi-document updates. Using two-phase commit ensures that data is consistent and, in case of an error, the state that preceded the transaction is recoverable.

Djongo comes with its own set of compromises, though. So what are the disadvantages of opting to use Djongo for your Django project?

Performance: The Django ORM does the heavy lifting of converting complex object manipulations to standard SQL query strings. If your backend database was SQL-based, you could pass this query string directly to it with almost no post-processing. With Djongo, however, the query string will now have to be converted into a MongoDB query document.

Dette vil kræve nogle CPU-cyklusser. Men hvis ekstra CPU-cyklusser virkelig er et sådant problem, bør du sandsynligvis ikke bruge Python i første omgang.

Konklusion

Jeg tog dig gennem flere måder at integrere Django med MongoDB. Du finder et væld af online litteratur, der beskriver MongoEngine og andre varianter til at gøre dette.

Jeg fokuserede på Djongo, som er et nyt stik, der gør dette muligt på en anden måde. Det er let at bruge og gør processen med at migrere fra en SQL-backend til MongoDB meget enkel ved kun at tilføje en kodelinje .