Edukia  TLDR - Django Transaction Logikaren laburpena  Diagrama logikoa  Transakzioak eta ATOMIC Eragiketak  Transakzioak Django-n  Django auto-commit modua — Transakzio automatikoak desaktibatu  Iturriak  TLDR - Django Transaction Logikaren laburpena  Hau Django exekutatzen duten aplikazioetarako da PSQL edo antzeko beste SQL (SQLite, MySQL, etab.) oinarritutako datu-baseekin (DB); transakzioen inguruko arauak baliteke beste DB batzuei ez aplikatzea. Kanpaiaren azpian, Django-ren transakzioak kudeatzeko kodeak honako hau egiten du (hau Django-ren   kopiatzen da -korritu behera- nire buletekin argitzeko): dokumentutik  Transakzio bat irekitzen du kanpoko bloke atomikoan sartzean;  DBrako konexioa lortzen edo sortzen du eta transakzio gisa ezartzen du.  Blokeoak eskatu eta eskuratzen ditu DB eragiketa bat aurkitzen denean;  DB eragiketa guztiek blokeoak behar dituzte — blokeo batzuk solteak dira eta beste konexio batzuek baliabide berean eragiketak egiteko aukera emango dute, baina beste blokeo batzuk zorrotzagoak dira; esklusiboak dira eta irakurketa eta idazketa eragiketak blokeatuko dituzte. Erregistroak sortu, eguneratu eta ezabatzeak, baita taulak eta zutabeak aldatzeak, blokeo zorrotzagoak eskuratuko ditu, beste konexio batzuk eragiketak exekutatzeko blokeoa egingo dutenak. Blokeo hauek transakzioaren AMAIERA arte mantentzen dira.  Gorde-puntu bat sortzen du barne bloke atomiko batean sartzean;  Hau automatikoki egiten da, adibidez, erregistroak taula batean txertatzean; eredu-eragiketa batzuk automatikoki bloke atomikoetan bilduko dira.  Hau eskuz egin daiteke atomic()-ek bilduta dagoen funtzio bati deituz edo atomic() erabiliz adierazpen batekin (testuinguru-kudeatzaile gisa).  Gorde puntuek kanpoko transakzioaren konexio bera erabiliko dute - Django kodea gordetzeko puntuetarako begiratzen baduzu, beste transakzio bat sortzeko dei errekurtsibo bat besterik ez da.  Gorde-puntuak gordetze-puntuetan habia daitezke - pila batek gordetze-puntuen jarraipena egiten du.  Barne bloke batetik irtetean gordetze-puntura askatzen edo atzera egiten du;  Txertatu ondoren, gordetzeko puntua kentzen da aldaketak konprometituz eta gainerako transakziorako eskuragarri jarriz (baina EZ beste konexio batzuk) edo aldaketak atzera botaz.  DB ukitzen ez duen kodea aurkitzen denean kodea ohi bezala exekutatzen da;  DBko blokeoak oraindik mantentzen dira DB ez den logika exekutatzen den bitartean, adibidez, transakzio baten gorputzean HTTP eskaera bat bidaltzen badugu, blokeoak mantendu egingo dira eskaera hori bidali eta erantzuna itzultzen den arte. Django-k ez ditu blokeoak askatzen DB eragiketak exekutatzen uzten ditugunean. Sarrailak mantentzen ditu kanpoko transakzioa amaitu ARTE.  Habiaratutako transakzioetan eskuratutako blokeoak ere mantentzen dira kanpoko transakzioa amaitu arte edo habiaratutako transakzioa atzera egin arte.  RuntimeError bat gertatzen denean edo DBtik kanpo akats bat sortzen denean (ez dago DBko eragiketekin);  Transakzioa gelditzen da, atzera egiten da eta blokeoak askatzen dira.  Errorea habiaratutako transakzio batean gertatzen bada, kanpoko transakzioak ez du eraginik izango. Atzera itzulia gertatzen da, baina kanpoko transakzioak etenik gabe jarrai dezake (betiere sortutako errorea atzeman eta kudeatzen bada).  Transakzioek ez dituzte akatsak antzematen, baina horien araberakoak dira aldaketak atzera egin behar diren jakiteko. Hori dela eta, ez biltzeko DB eragiketak try/salbu, baizik eta itzulbiratu transakzio batean eta, ondoren, itzulbiratu transakzioa try/salbu. Hori eginez gero, DB eragiketak huts egiten du eta automatikoki atzera egiten du kanpoko transakzioan eragin gabe.  Transakzioa konprometitzen edo atzera egiten du kanpoko bloketik irtetean.  Azkenik, transakzio osoa konprometituta dago, aldaketak DB erabiltzaile/konexio guztien eskura jarriz. Edo atzera botatzen da, DB transakzioa aurkitu zenean zegoen egoera berean utziz.  Hurrengo blogean, sarrailak goseteak eragindako etenaldiak saihesteko transakzio batean jarri behar duzunari buruz idatziko dut.  Diagrama logikoa   Transakzioak eta ATOMIC Eragiketak  Transakzioak   DB-ak (PSQL, SQL, azken   , etab.)   (A ACID-en) izatea ahalbidetzen duten mekanismoak dira. Horrek esan nahi du DBrako idazketa guztiak eragiketa bakar gisa egiten direla, nahiz eta konplexua izan. Idazketa arrakastatsua bada, DBko aldaketa guztiek iraun egiten dute eta konexio guztietarako erabilgarri egongo dira aldi berean (idazketa partzialik ez). Idazteak huts egiten badu, aldaketa guztiak atzera egiten dira; berriro ere, ez dago aldaketa partzialik. ACID MongoDB ATOMIC  Transakzioek arau hauek bermatzen dituzte:  DBko datuak ez dira aldatuko transakzio baten erdian.  Beste konexiorik ezingo du ikusi transakzioak egindako aldaketak amaitu arte.  DBak datu berri guztiak edo bat ere ez izango ditu.  Arau hauei esker, DBko erabiltzaileak eragiketa konplexuak bildu eta eragiketa bakarrean exekutatu ditzake. Adibidez, banku-kontu batetik bestera transferentzia egitea; transakziorik ez bagenu, orduan, bi idazketa eragiketa horien erdian, transferentzia baliogabe bihurtzen duen kentze bat edo baita kontu itxi bat ere egon liteke. Transakzioek trafikoa kontrolatzeko modua ematen diote erabiltzaileari. Gatazkako beste eragiketa guztiak blokeatu ditzakegu transakzioa abian den bitartean.  Eragiketak tauletan eta errenkadetan blokeo batzuen bidez blokeatzen dira. PSQL eta beste SQL aldaeretan, transakzioak BEGIN-ekin sortzen dira; gero blokeoak eskuratzen dira hautatu/txertatu/ezabatu/alter bezalako eragiketa bat exekutatzen denean eta transakzioak COMMIT edo ROLLBACK-ekin amaitzen direnean. Blokeoak askatzen dira COMMIT edo ROLLBACK exekutatzen direnean. Zorionez, Django-k hiru adierazpen hauek erabili behar izan gabe transakzioak sortzeko aukera ematen digu (baina oraindik blokeoez kezkatu behar dugu; horri buruz gehiago hurrengo mezuan).   -- Start a new transaction BEGIN; SELECT … INSERT INTO … UPDATE … DELETE FROM … -- Save the changes COMMIT;  Hautatzaileak irakurtzen ari diren errenkadetan eguneraketak blokeatzen dituzten blokeoak eskuratzen ditu.  Txertaketak sortzen ari diren errenkadetan eguneraketak blokeatzen dituzten blokeoak eskuratzen ditu.  Eguneratzeak eguneratzen ari diren errenkadetan eguneraketak blokeatzen dituzten blokeoak eskuratzen ditu.  Ezabatzeak ezabatzen ari diren errenkadetan eguneraketak blokeatzen dituzten blokeoak eskuratzen ditu.  Ez dugu esplizituki egiaztatu behar errorerik dagoenik eta ROLLBACK deitu beharrik; transakzioak hau egiten digu.  Bertan aldatzeko taula eragiketa bat egongo balitz, mahai gainean dauden irakurketa eta idazketa guztiak blokeatuko lituzke (hori buruzko informazio gehiago hurrengo blogean).  Transakzioak Django-n   from django.db import transaction from app.core.models import Accounts, Fee, NotificationJob def do_migration(): overdrawn_accounts = Accounts.objects.filter(type='overdrawn') for acount in overdrawn_accounts: create_notification(acount) @transaction.atomic def create_notification(acount: Accounts): # $5 fee for overdraft - 500 because we never store money as float!!! recall = Fee.objects.create(acount=acount, description='Fee for overdraft', amount=500) NotificationJob.objects.create(recall=recall, notification_type='all') acount.status = 'awaiting_payment' acount.save() def do_migration2(): overdawn_account = Accounts.objects.filter(type='overdrawn') for account in overdawn_account: with transaction.atomic(): recall = Fee.objects.create(acount=account, description='Fee for overdraft', amount=500) NotificationJob.objects.create(recall=recall, notification_type='all') account.status = 'awaiting_payment' account.save()  Django-k automatikoki biltzen ditu DB eragiketa guztiak   batean autokonpromiso moduan exekutatzen direnean (behean gehiago).   atomic() dekoratzailea edo testuinguru-kudeatzailea erabiliz sor daitezke (atomic()-rekin) — atomic() erabiltzen denean, DB eragiketa indibidualak EZ dira transakzio batean biltzen edo berehala DBan konprometitzen dira (exekutatzen dira, baina DBan egindako aldaketak ez dira beste erabiltzaileentzat ikusgai). Horren ordez, funtzio osoa transakzio bloke batean bilduta dago eta amaieran konprometitzen da (akatsik sortzen ez bada) - COMMIT exekutatzen da. transakzio Transakzio esplizituak  Akatsak badira, DB-ko aldaketak atzera egiten dira — ROLLBACK exekutatuko da. Horregatik, transakzioek blokeoei eusten diete amaiera arte; ez dugu nahi mahai baten blokeorik askatu, beste konexio batek taula aldatzea edo irakurtzea, eta gero aldatu edo irakurri berri dena atzera egitera behartuta egon.   ANGRY_CUSTOMER_THRESHOLD = 3 @transaction.atomic def create_notification(acount: Accounts): recall = Fee.objects.create(acount=acount, description='Fee for overdraft', amount=500) NotificationJob.objects.create(recall=recall, notification_type='all') try: # when this completes successfully, the changes will be available to the outer transaction with transaction.atomic(): owner = acount.owner fees = Fee.objects.filter(owner=owner).count() if fees >= ANGRY_CUSTOMER_THRESHOLD: for fee in fees: fee.amount = 0 fee.save() owner.status = 'angry' owner.save() # as long as we catch the error, the outer transaction will not be rolled back except Exception as e: logger.error(f'Error while removings fees for account {acount.id}: {e}') acount.status = 'awaiting_payment' acount.save()  Transakzioak ere habia ditzakegu atomic()-ek bilduta dagoen beste funtzio bati deituz edo transakzio baten barruan testuinguru-kudeatzailea erabiliz. Horri esker, salbatzeko puntuak sor ditzakegu, non eragiketa arriskutsuak saia ditzakegun gainerako transakzioari eragin gabe: barne-transakzio bat detektatzen denean, gordetze-puntu bat sortzen da, barne-transakzioa exekutatzen da eta barne-transakzioak huts egiten badu, datuak gordetzeko puntura itzultzen dira eta kanpoko transakzioak jarraitzen du. Kanpoko transakzioak huts egiten badu, barruko transakzio guztiak atzera egiten dira kanpoko transakzioarekin batera. Transakzioen habiaratzea ekidin daiteke durable=True ezarriz atomic() - honek transakzioak RuntimeError bat sortuko du barne-transakzioren bat detektatzen bada.  Habiaratutako transakzioei buruz gogoratu behar duzuna:  Habiaratutako transakzioek EZ dituzte blokeoak askatzen habiaratutako transakzioak atzera egiten ez badira edo kanpoko transakzioa konprometitu edo atzera egiten ez bada.  Habiaratutako transakzioek EZ DITU DB akatsak harrapatzen; akatsa eragin duen transakzioaren eragiketak atzera bota besterik ez dute egiten. Oraindik ere DB akatsa harrapatu behar dugu kanpoko transakzioak jarraitzeko.  Habiaratutako transakzioetan egindako aldaketak kanpoko transakziorako eta ondorengo habiaratutako transakzioetarako eskuragarri daude.  Django Autocommit modua — Transakzio automatikoak desaktibatu   DATABASES = { 'default': { # True by default 'AUTOCOMMIT': False, # ...rest of configs } }  Lehenespenez, Django   moduan exekutatzen da, hau da, DB eragiketa bakoitza transakzio batean bilduta dagoela eta berehala exekutatzen da (konpromisoa, beraz, autokonpromisoa) erabiltzaileak eragiketa esplizituki transakzio batean biltzen badu izan ezik. Honek azpiko DBren transakzio-logika nahasten du - DB batzuek, PSQL bezalakoak, eragiketa guztiak automatikoki biltzen dituzte transakzioetan, beste batzuek ez. Djangok hau egiten badugu, ez dugu azpian dagoen DB logikarekin kezkatu beharrik. autocommit  Autokonpromiso modua desaktibatu dezakegu, baina horrek DBn fidatuko gintuzke eragiketak kudeatzeko eta ATOMICak direla ziurtatzeko, eta hori arriskutsua eta deserosoa da garatzaileentzat. Ez litzateke dibertigarria izango, API bat sortzean, transakzioetan zein idazketa-eragiketa dauden asmatu beharko bagenu eta, beraz, guztiz idatziko dira eta ez partzialki.  Hala ere, baliteke   nahi izatea DBko konexio kopurua eta exekutatzen ari diren eragiketen sekuentzia ezagutzen baditugu. Eragiketa hauek gatazkak nola desagerrarazi nahi baditugu, autokonpromiso modua desaktibatu eta eraginkortasun batzuk lor ditzakegu: autokonpromiso modua desaktibatu  Eragiketa guztietatik bi komando kentzen ditugu: BEGIN eta COMMIT/ROLLBACK. Baina DB gehienek eragiketa guztiak automatikoki biltzen dituzte transakzio batean, beraz, hau alferrikakoa izan daiteke.  Blokeoak ez dira denbora gehiegi edukiko: eragiketa bat amaitu bezain laster, dauzkan blokeoak askatzen dira, transakzio osoa noiz amaituko zain egotearekin alderatuta.  Blokeoak ez dira litekeena - blokeoak gertatzen dira bi transakziok beste transakzioak duen blokeoa behar dutenean. Horrek bi transakzioak bestea noiz amaitu zain uzten ditu, baina batak ez besteak ezin du amaitu. Hala ere, blokeoak gerta daitezke. DB eragiketa batzuek hainbat idazketa egingo dituzte, adibidez, indizea duen zutabe bat eguneratzeak zutabea eta indizea eguneratuko ditu (bi idazketa gutxienez). Horrek blokeoak ekar ditzake beste konexio batek eragindako errenkada edo zutabeetan funtzionatzen saiatzen bada.  Alde txarrak datuak usteltzeko arrisku handiagoak dira. Ez du merezi, baina agian bada pentsatu ezin dudan erabilera kasuren bat.  Iturriak   AZIDOA   ATOMIKOA   Django - atomikoa   Django - autokonpromisoa   Django — autokonpromiso dokumentuak   Django - transakzio esplizituak   Django - transakzioak   MongoDB - transakzioak   PSQL - blokeoak   PSQL - transakzioak

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Audio hau istorioaren jatorrizko hizkuntzan ekoitzi da!

Python: Django transakzioen funtzionamenduari buruzko begirada sakonagoa

About Author

IRUZKINAK

ESKEGI ETIKETAK

ARTIKULU HAU AURKEZTU ZEN

Related Stories

SECONDARY SEXUAL CHARACTERS OF MAN

"Crypto Payments Will Become Commonplace In the Next 5 Years" - CoinsPaid’s CMO Eugen Kuzin

The Most Consequential Technology Stories of 2023, According to HackerNoon Editors

THE SWORD OF PEACE

SECONDARY SEXUAL CHARACTERS OF MAN

"Crypto Payments Will Become Commonplace In the Next 5 Years" - CoinsPaid’s CMO Eugen Kuzin

The Most Consequential Technology Stories of 2023, According to HackerNoon Editors

THE SWORD OF PEACE

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps