SQLAlchemy

Salut, sunt Alex de la DEV STORIES DOT EU. SQLAlchemy, episodul 1 din 7. Ai dat vreodată drop accidental unui tabel sau ai stricat un query din cauza unui typo într-un string SQL raw? Query-urile concatenate din string-uri sunt fragile, greu de întreținut și reprezintă un risc de securitate. Acest episod acoperă soluția: Fundamentul: Ce este SQLAlchemy și ORM-ul? Problema principală cu care se confruntă developerii când scriu aplicații cu baze de date este că Python și bazele de date relaționale gândesc diferit. Python folosește obiecte. Obiectele au stare, comportament și relații complexe. Bazele de date relaționale folosesc tabele, coloane și rânduri. Ele se bazează pe primary și foreign keys. Introducerea unui obiect Python într-un tabel din baza de date necesită traducerea stării sale într-un statement SQL. Recuperarea lui necesită parsarea rândurilor și repopularea unui obiect nou. Această fricțiune se numește object-relational impedance mismatch. Scrierea de string-uri SQL raw pentru a gestiona această traducere este plictisitoare și predispusă la erori. SQLAlchemy este un toolkit SQL pentru Python conceput pentru a rezolva exact această problemă. Spre deosebire de unele tool-uri care încearcă să ascundă baza de date în spatele unui zid de abstracție, SQLAlchemy îmbrățișează SQL-ul. Oferă un workflow robust, Pythonic, care generează SQL optim, lăsându-ți în același timp controlul. Arhitectura este împărțită în două părți distincte: Core-ul și ORM-ul. Core-ul SQLAlchemy este fundația. Este orientat pe comenzi și pe schema. Asta înseamnă că lucrezi direct cu tabelele, coloanele și rândurile bazei de date, dar o faci folosind obiecte Python în loc de string-uri de text raw. Dacă vrei să selectezi date, apelezi o metodă select. Dacă vrei să filtrezi, faci chain la o metodă where. Asta elimină riscul erorilor de sintaxă cauzate de concatenarea de string-uri și te protejează împotriva SQL injection. Core-ul este în esență un limbaj de expresii SQL. ORM-ul, sau Object Relational Mapper, stă deasupra Core-ului. În timp ce Core-ul este orientat pe schema, ORM-ul este orientat pe stare și domeniu. Iată ideea cheie. Cu ORM-ul, nu te mai gândești la tabele și rânduri și începi să te gândești la domain model-ul aplicației tale. Definești o clasă Python standard, de exemplu, o clasă user. Configurezi ORM-ul pentru a mapa această clasă la un tabel user din baza de date și pentru a mapa atributele clasei la coloanele tabelului. Când faci query în baza de date folosind ORM-ul, nu primești înapoi rânduri raw de date. Primești înapoi instanțe complet populate ale clasei tale user. ORM-ul gestionează traducerea fără probleme. Mai important, urmărește starea acelor obiecte. Dacă schimbi un nume de utilizator în Python, ORM-ul observă că obiectul a fost modificat. Când îi spui sesiunii bazei de date să salveze modificările, ORM-ul identifică automat statement-urile de update corecte și le execută prin Core. Tu te concentrezi pe obiectele Python, iar ORM-ul gestionează sincronizarea cu baza de date. Cel mai important lucru de reținut este că ORM-ul nu este o cutie neagră care înlocuiește Core-ul. Este un strat opțional construit în întregime din componente Core, permițându-ți să treci fără probleme la generarea de SQL explicit ori de câte ori logica domeniului tău necesită performanță maximă. Dacă găsești aceste episoade utile și vrei să susții emisiunea, poți căuta DevStoriesEU pe Patreon. Mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. SQLAlchemy, episodul 2 din 7. Vrei să comunici cu o bază de date, dar bazele de date diferite vorbesc dialecte diferite, iar driverele Python au toate propriile particularități. Ai nevoie de o componentă unificată care să gestioneze connection pooling-ul, traducerea dialectelor și managementul driverelor, fără să expună aceste detalii în logica aplicației tale. Această componentă este Engine-ul. Engine-ul este punctul de plecare pentru orice aplicație SQLAlchemy. Acționează ca un registru central și un factory pentru conexiunile la baza de date. Când aplicația ta trebuie să comunice cu baza de date, în cele din urmă trece prin Engine. În culise, Engine-ul ține un connection pool. Asta înseamnă că menține un cache de conexiuni active la baza de date, păstrându-le deschise și gata de utilizare. Reutilizarea conexiunilor dintr-un pool este mult mai rapidă decât negocierea unei conexiuni de rețea complet noi de fiecare dată când trebuie să execuți un query. Pentru a instanția un Engine, folosești o funcție numită create engine. Această funcție necesită un URL pentru baza de date. URL-ul este un string care furnizează locația bazei de date, credențialele și două elemente esențiale de configurare: dialectul și DBAPI-ul. Dialectul este familia de baze de date pe care o țintești. SQL este un standard, dar fiecare engine de baze de date îl implementează puțin diferit. Dialectul îi spune lui SQLAlchemy dacă formatează query-uri pentru PostgreSQL, MySQL, Oracle sau SQLite. Acesta gestionează toate variațiile specifice vendorului, astfel încât codul tău Python să rămână consistent. Iată ideea de bază. SQLAlchemy nu se conectează direct la baza ta de date. Deleagă întotdeauna comunicarea efectivă de rețea către un driver Python third-party. Acest driver este cunoscut sub numele de DBAPI. Dacă folosești PostgreSQL, DBAPI-ul tău ar putea fi psycopg2. Dacă folosești SQLite, acesta este de obicei pysqlite. URL-ul bazei de date le specifică pe amândouă împreună. De exemplu, URL-ul ar putea începe cu string-ul sqlite plus pysqlite. Asta îi spune în mod explicit Engine-ului să formateze query-urile folosind dialectul SQLite și să le transmită folosind driverul pysqlite. Hai să ne uităm la configurarea unei baze de date SQLite in-memory. Acesta este un pattern foarte comun pentru testare, deoarece baza de date trăiește în întregime în RAM și dispare când programul se închide. Apelezi funcția create engine și îi pasezi string-ul URL. Pentru o bază de date in-memory, URL-ul este sqlite plus pysqlite colon slash slash slash colon memory colon. Când rulezi acea linie de cod, obiectul Engine este creat, dar nu se conectează imediat la baza de date. Engine-ul este lazy. Pregătește configurația și setează connection pool-ul, dar așteaptă până prima dată când îi ceri explicit să execute un task, înainte să contacteze efectiv DBAPI-ul pentru a stabili o conexiune. În timpul dezvoltării, ai adesea nevoie să verifici exact ce trimite SQLAlchemy către baza de date. Funcția create engine acceptă un parametru opțional numit echo. Dacă setezi echo pe true, Engine-ul va face log la toate statement-urile SQL raw pe care le generează, direct în standard output. Acționează ca un tool de debugging built-in, permițându-ți să vezi traducerea exactă dintre operațiile tale Python și SQL-ul rezultat. Engine-ul există pentru a abstractiza realitatea dezordonată a conexiunilor de rețea și a driverelor de baze de date. Oferă aplicației tale o interfață curată și stabilă, asigurându-se că restul codului tău nu trebuie să se preocupe niciodată de modul în care baza de date este accesată fizic. Mersi că ai stat cu mine. Sper că ai învățat ceva nou.

Salut, sunt Alex de la DEV STORIES DOT EU. SQLAlchemy, episodul 3 din 7. Îți scrii modelele de domeniu în Python, și apoi trebuie să scrii o grămadă de cod SQL separat doar pentru a crea tabelele care să le conțină. În timp, aceste două definiții separate ajung aproape mereu să se desincronizeze. Ce-ar fi dacă acele clase Python ar putea proiecta automat schema bazei de date? Exact asta rezolvăm astăzi cu Mapping the Domain: Declarative Base și Models. Înainte să ne uităm la clase în sine, trebuie să vorbim despre metadata bazei de date. În SQLAlchemy, metadata este practic un catalog structural. Este un registry central în Python care stochează blueprint-ul exact al bazei de date. Urmărește fiecare tabel, fiecare coloană și fiecare constrângere pe care o definești. De fiecare dată când mapezi o clasă în SQLAlchemy, detaliile acelei clase ajung direct în acest catalog unic. Pentru a-ți conecta clasele Python la acest catalog de metadata, folosești un construct numit DeclarativeBase. Nu folosești DeclarativeBase în mod direct. În schimb, îți creezi propria ta clasă de bază custom, moștenind din ea. Din acel moment, absolut fiecare model pe care îl construiești în aplicația ta va moșteni din clasa ta de bază custom. În momentul în care o clasă moștenește din ea, SQLAlchemy înregistrează tăcut acel nou model în catalogul de metadata din spate. Gândește-te cum creezi un model User. Definești o clasă Python numită User și moștenești din clasa ta de bază custom. Primul lucru pe care îl definești în interiorul acestei clase este un atribut numit tablename, scris cu două underscore-uri pe fiecare parte. Îl setezi la string-ul user_account. Această atribuire explicită îi spune lui SQLAlchemy exact ce tabel din baza de date din spate va stoca aceste obiecte Python. Apoi, stabilești coloanele. SQLAlchemy 2.0 se bazează pe type hints standard din Python pentru a face asta. Îți definești atributele folosind o adnotare specială numită Mapped. Pentru un identificator, îți adnotezi atributul ID ca Mapped care conține un integer. Pentru un username, îl adnotezi ca Mapped care conține un string. Acest type hint este strict pentru Python. Îi spune IDE-ului tău și type checker-ului ce date să aștepte. Dar motorul bazei de date are nevoie de instrucțiuni mai specifice decât un simplu tip din Python. Aici intră în joc o funcție numită mapped_column. Atribui mapped_column atributului clasei tale, iar în parantezele sale, configurezi regulile specifice bazei de date. Pentru ID-ul tău de user, apelezi mapped_column și pasezi un flag care îl marchează explicit drept primary key. Pentru o coloană de tip string, ai putea să pasezi o limită maximă de caractere sau un flag care cere ca field-ul să fie unic. Dacă type hint-ul tău din Python oferă tot contextul de care are nevoie SQLAlchemy, poți de fapt să omiți complet mapped_column. SQLAlchemy va deduce o coloană de bază, standard, pentru baza de date direct din adnotarea Mapped. Dar pentru primary keys, sau orice constrângeri specifice bazei de date, mapped_column este strict necesar. Aici e partea esențială. Odată ce clasele tale Python sunt scrise, designul schemei tale este deja gata. Catalogul de metadata conține acum o hartă perfectă a domeniului tău. Poți apela o metodă numită create_all pe metadata clasei tale de bază, pasând motorul bazei de date. SQLAlchemy se uită la clasa ta User, citește coloanele mapate, le traduce instantaneu în statement-uri CREATE TABLE perfect formatate și le aplică. Exact același cod Python pe care îl scrii pentru a-ți rula aplicația devine acel single source of truth care construiește structura bazei de date. Mersi că ai fost alături de mine. Sper că ai învățat ceva nou.

Salut, sunt Alex de la DEV STORIES DOT EU. SQLAlchemy, episodul 4 din 7. Ți-ai scris modelele, engine-ul și query-urile. Dar să le arunci pe toate într-un singur fișier este o cale rapidă către un coșmar de mentenanță și circular imports. Soluția este Project Layout: Structuring Your Application. Când te uiți la tutoriale, codul este de obicei pus într-un singur script. Vezi setup-ul engine-ului, base class-ul, modelele și query-urile înșirate de sus până jos. Acest design este excelent pentru a învăța sintaxa, dar dacă încerci să construiești un sistem de producție în felul ăsta, se va destrăma. De îndată ce adaugi web routes sau background workers, dai de probleme. Dacă un web route trebuie să importe un model de user, dar modelul de user este în același fișier care pornește application server-ul sau inițializează conexiunea la baza de date, Python se încurcă. Ajungi la circular imports, iar codul tău devine imposibil de testat. Ai nevoie de un separation of concerns strict. Pattern-ul standard este să împarți acel singur script în module distincte, în funcție de rolul lor. Mai întâi, creezi un fișier dedicat, de obicei numit database dot py. Acest fișier are exact o singură responsabilitate, și anume gestionarea conexiunii la baza de date. Aici pui apelul de create engine și îți setezi session maker-ul. Nu definești tabele aici și nu rulezi query-uri aici. Izolând engine-ul, te asiguri că aplicația ta creează un singur connection pool. Orice alt modul din proiectul tău poate importa în siguranță session maker-ul din acest fișier, fără să declanșeze accidental logica de startup a aplicației. Apoi, îți muți definițiile tabelelor într-un fișier numit models dot py. Acest fișier conține Declarative Base-ul tău și toate acele mapped classes, cum ar fi un obiect User sau Address. Nu importă nimic din fișierul tău de database. Asta e partea care contează. Modelele tale definesc forma datelor tale, dar nu știu cum să se conecteze la baza de date. Pentru că models dot py nu are dependențe de engine sau de sesiunea activă, poți importa acele mapped classes oriunde în aplicația ta, fără să-ți faci griji de side effects. Dacă proiectul tău crește, poți chiar să împarți modelele într-un director cu fișiere separate pentru domenii diferite. Atâta timp cât toate importă exact aceeași instanță de Declarative Base, SQLAlchemy știe că aparțin aceleiași colecții de metadata. În cele din urmă, ai nevoie de un loc unde să execuți efectiv query-urile. Ții execuția de query-uri complet separată de modelele și fișierele tale de conexiune. De obicei, asta merge în route handlers sau în fișiere de service dedicate. Când o aplicație are nevoie de date, fișierul de service importă session maker-ul din modulul tău de database și acele mapped classes necesare din modulul de modele. Deschide o sesiune folosind un context manager, rulează un select statement, preia obiectele și lasă context manager-ul să închidă în siguranță conexiunea atunci când blocul se termină. Fișierul de service acționează ca un coordonator. Structurarea proiectului în felul ăsta îți menține logica de conexiune izolată, data schemas portabile și operațiunile de business curate. Cea mai importantă regulă de reținut este că modelele tale de date nu ar trebui să importe niciodată database engine-ul. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. SQLAlchemy, episodul 5 din 7. Imaginați-vă un staging area unde puteți pune în coadă zeci de modificări ale bazei de date și le puteți da push tuturor perfect simultan, sau le puteți anula instantaneu. Asta e exact problema rezolvată de conceptul din acest episod: Session-ul: Stăpânirea Unit of Work-ului. Session-ul SQLAlchemy este principala modalitate prin care obiectele voastre Python comunică cu baza de date. Funcționează pe baza unui pattern numit Unit of Work. Când folosiți Session-ul, nu executați comenzi individuale direct către baza de date. Interacționați cu un workspace inteligent. Session-ul vă urmărește operațiunile, colectează adăugările, modificările și ștergerile și calculează cea mai eficientă modalitate de a le traduce în SQL atunci când e momentul potrivit. În interiorul acestui workspace se află un mecanism numit Identity Map. Acesta este un dicționar intern care leagă primary key-ul unui rând din baza de date de adresa de memorie specifică a obiectului vostru Python. Dacă cereți un user cu ID-ul cinci, Session-ul verifică mai întâi Identity Map-ul. Dacă obiectul este deja încărcat, primiți înapoi exact aceeași instanță Python. Asta garantează că nu veți avea niciodată două obiecte Python distincte care reprezintă același rând din baza de date în același timp. Hai să ne uităm la inserarea de date noi. Începeți prin a crea o instanță a clasei User mapate, dându-i un nume precum Alice. În această etapă, obiectul vostru se află într-o stare numită transient. Există exclusiv în memoria Python. Baza de date habar n-are că există, iar Session-ul nu știe de el. Pentru a lega obiectul de workspace-ul vostru, îl pasați în metoda add a Session-ului. Obiectul trece într-o stare numită pending. Session-ul a înregistrat intenția voastră de a insera acest nou user, dar nu a trimis încă niciun SQL prin rețea. Obiectul așteaptă pur și simplu în coadă. Asta introduce diferența strictă dintre un flush și un commit. Când apelați flush pe Session, acesta preia coada voastră de pending și dă push la modificări în tranzacția curentă a bazei de date. Emite statement-ul SQL INSERT. Baza de date îl execută și îi atribuie un primary key. Înapoi în codul vostru Python, obiectul user este populat instantaneu cu acel nou ID din baza de date. Obiectul a trecut în starea persistent. Aici e ideea cheie. Chiar dacă obiectul este persistent și are un ID, modificarea tot nu e permanentă. Baza de date izolează această tranzacție. Să presupunem că, brusc, codul vostru detectează o greșeală, cum ar fi o adresă de email invalidă pentru userul căruia tocmai i-ați dat flush. Pentru că nu ați dat commit, puteți da un rollback. Baza de date elimină complet tranzacția și nimic nu este salvat în tabelele reale. Când sunteți absolut siguri că datele sunt corecte, apelați commit. Un commit finalizează tranzacția și salvează datele pe disk. Apelarea lui commit declanșează automat un flush mai întâi, așa că, în general, nu e nevoie să apelați flush manual, decât dacă aveți nevoie în mod specific să citiți un primary key generat înainte de a finaliza restul logicii. Session-ul acționează ca un buffer între memoria aplicației voastre și storage-ul permanent, permițându-vă să orchestrați modificări complexe de date în siguranță înainte de a le face permanente. Mulțumesc pentru ascultare. Aveți grijă de voi, tuturor.

Salut, sunt Alex de la DEV STORIES DOT EU. SQLAlchemy, episodul 6 din 7. În versiunile mai vechi de SQLAlchemy, să scrii query-uri se simțea ca și cum ai lucra cu un creier divizat. Trebuia să memorezi o sintaxă pentru operațiile Core și un set complet diferit de reguli pentru ORM. De fiecare dată când scriai un query, trebuia să te oprești și să te întrebi dacă faci fetch la raw rows sau la mapped objects. Versiunea 2.0 a șters acea linie cu constructul modern Select. Conceptul este simplu. Acum există o singură funcție unificată numită select. Îi pasezi direct entitatea pe care vrei să faci query. Dacă ai o clasă ORM numită User, pasezi clasa User funcției select. Asta creează un obiect select care reprezintă un query pe tabelul user din spate. Acest obiect select este generativ. Apelarea funcției select nu execută nimic pe baza de date. În schimb, creează un expression object în memorie. Când apelezi o metodă pe acest obiect pentru a adăuga condiții, el returnează un obiect select nou, cu acele condiții aplicate. Asta îți permite să construiești query-uri complexe dinamic, pas cu pas, pasând obiectul prin aplicație înainte să comunici vreodată cu baza de date. Asta acoperă query-ul de bază. Cum îl filtrezi? Adaugi metoda where la obiectul tău select. În interiorul metodei where, folosești operatori Python standard direct pe atributele clasei tale mapate. De exemplu, pentru a găsi un anumit user, scrii clasa User punct name, urmat de două semne de egal și target string-ul. SQLAlchemy interceptează asta. Face overload la operatorii Python standard, cum ar fi dublu egal sau semnul mai mare decât. În loc să evalueze expresia la true sau false în Python, o traduce în sintaxa SQL corectă pentru clauza WHERE din baza de date. Acum ai un query object complet construit. Ca să îți recuperezi efectiv datele, pasezi acest obiect unei sesiuni. Îl poți pasa metodei standard execute de pe sesiune, dar asta returnează un result object în care fiecare rând este, în esență, un tuple. Chiar dacă ai făcut query pe o singură clasă ORM, obiectul tău mapat este blocat într-un tuple cu un singur element și trebuie să îl extragi manual la returnare. Iată ideea cheie. Când vrei să primești înapoi obiecte ORM, folosește în schimb metoda scalars de pe sesiune. Pasezi obiectul tău select către session punct scalars. Sesiunea rulează query-ul, face unwrap automat la acele tuple-uri din result set-ul din spate și dă yield la un iterable cu obiectele tale ORM complet populate. Obții imediat o colecție curată de instanțe User, gata să fie modificate sau citite. Constructul select unificat înseamnă că exact aceleași query building blocks pe care le folosești pentru obiectele ORM pot fi executate direct pe conexiuni Core low-level, lăsându-te cu un singur model mental de menținut pentru întregul tău database layer. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. SQLAlchemy, episodul 7 din 7. Bazele de date relaționale există pentru că datele se conectează, dar să scrii manual join-uri complexe de fiecare dată când ai nevoie de o înregistrare relaționată devine obositor repede. Ajungi să ai o logică de query repetitivă, împrăștiată prin toată aplicația. „Connecting the Dots: Relationships and Joins” rezolvă asta lăsând object-relational mapper-ul să gestioneze conexiunile pentru tine. La nivel de bază de date, tabelele se conectează folosind foreign keys. Dacă un user are mai multe adrese, tabelul de adrese are o coloană care stochează ID-ul user-ului. Asta este o relație standard one-to-many. Dar când scrii cod Python, nu vrei să extragi un ID și să scrii un al doilea query doar ca să găsești acele adrese. Vrei să accesezi o proprietate pe obiectul tău user și să vezi instant o listă de obiecte address. Exact asta oferă constructul de relationship. El face puntea între foreign keys din baza de date și atributele obiectelor din Python. Ca să setezi asta, ai nevoie de două lucruri. În primul rând, declari foreign key-ul pe partea de bază de date. În modelul Address, definești o coloană numită user ID și o marchezi explicit ca un foreign key care pointează către tabelul User. În al doilea rând, definești relationship-ul pe partea de Python. În modelul User, definești o proprietate numită addresses, folosind funcția relationship, care pointează către modelul Address. De asemenea, definești o proprietate de relationship pe modelul Address care pointează înapoi către User. Aici e ideea principală. SQLAlchemy trebuie să știe că aceste două proprietăți reprezintă cele două capete ale exact aceleiași conexiuni. Îi spui asta folosind parametrul back populates pe ambele definiții de relationship. Pe modelul User, relationship-ul addresses setează back populates la string-ul cu numele proprietății user. Pe modelul Address, relationship-ul user setează back populates la string-ul cu numele proprietății addresses. Datorită back populates, ORM-ul îți menține obiectele Python sincronizate în memorie. Dacă iei un obiect address și îl atribui unui user, acea adresă apare instant în lista de adrese a user-ului. Framework-ul se ocupă de toată evidența înainte ca tu să dai commit la ceva în baza de date. Odată ce obiectele tale sunt legate, le faci query. Să presupunem că execuți un select ca să găsești un user pe nume Alice. Baza de date returnează rândul user-ului, iar tu primești un obiect. În acest moment exact, adresele lui Alice nu sunt încărcate. ORM-ul nu le aduce pentru că nu le-ai cerut încă. Când accesezi în sfârșit proprietatea addresses în codul tău, poate pentru a itera prin numele străzilor, ORM-ul observă că datele lipsesc. Pune automat programul pe pauză, emite un al doilea select către baza de date pentru a găsi toate adresele cu ID-ul lui Alice și populează lista. Asta se numește lazy loading. Este comportamentul default pentru că previne aplicația din a trage mii de rânduri relaționate în memorie, cu excepția cazului în care sunt strict necesare. Faci un query pe un user, îi accesezi proprietățile, iar sistemul navighează fluid prin foreign keys și emite query-urile necesare în background. Adevărata putere a constructului de relationship este că ascunde complexitatea mecanică a join-urilor, lăsându-te să navighezi printr-o întreagă bază de date doar interacționând cu obiecte Python conectate. Ca să stăpânești aceste concepte, explorează documentația oficială și încearcă să-ți setezi propriile modele hands-on. Nu ezita să vizitezi devstories dot eu ca să sugerezi subiecte pe care vrei să le acoperim în seriile viitoare. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!