035.3 Lecke 1

A Structured Query Language az adatbázisokra jellemző. Az írási és olvasási műveleteket statements (állítások) és queries (lekérdezések) nevű mondatokban fejezzük ki. Mind az állítások, mind a lekérdezések kifejezésekből állnak, amelyek meghatározzák a művelet végrehajtásának feltételeit.

Neveket és e-mail címeket például tárolhatunk egy olyan adatbázis-táblában, amely tartalmazza a name és az email mezőket. Egy adatbázis több táblát is tartalmazhat, ezért minden táblának egyedi névvel kell rendelkeznie. Ha a contacts nevet használjuk a nevek és e-mail címek táblához, akkor egy új rekordot a következő statement-tel (állítással) lehet beszúrni:

Ez a beszúrási utasítás az INSERT INTO záradékból áll, amely meghatározza a táblát és a mezőket, ahová az adatok beillesztésre kerülnek. A második, VALUES záradék a beszúrandó értékeket határozza meg. A záradékokat nem szükséges nagybetűvel írni, de ez a bevett gyakorlat, azért, hogy az SQL kulcsszavakat jobban felismerjük egy utasításon vagy lekérdezésen belül.

A kapcsolatok táblából való lekérdezés hasonló módon történik, de a SELECT záradék használatával:

Ebben az esetben a SELECT email záradék egy mezőt választ ki a contacts tábla bejegyzéseiből. A WHERE záradék a lekérdezést meghatározott sorokra korlátozza:

Az SQL-nek számos más záradéka is van, és ezek közül néhányat a későbbi szekciókban fogunk megvizsgálni. De előbb meg kell néznünk, hogyan integráljuk az SQL-adatbázist a Node.js-be.

Az SQLite valószínűleg a legegyszerűbb megoldás az SQL-adatbázis funkcióinak beépítésére egy alkalmazásba. Más népszerű adatbázis-kezelő rendszerekkel ellentétben az SQLite nem egy adatbázis-kiszolgáló, amelyhez a kliens csatlakozik. Az SQLite számos olyan funkciót biztosít, amelyek lehetővé teszik a fejlesztő számára, hogy hagyományos fájlként hozzon létre egy adatbázist. A Node.js Express-szel megvalósított HTTP-szerver esetében ez a fájl általában a szerverszkripttel azonos könyvtárban található.

Az SQLite Node.js-ben való használata előtt telepíteni kell az sqlite3 modult. Futtassuk a következő parancsot a szerver telepítési könyvtárában; azaz abban a könyvtárban, amely a futtatni kívánt Node.js szkriptet tartalmazza.

Ne felejtsük el, hogy több modul is támogatja az SQLite-ot, például a better-sqlite3, amelynek használata egy kicsit eltér az sqlite3-tól. A leckében szereplő példák a sqlite3 modulra vonatkoznak, így előfordulhat, hogy nem a várt módon működnek, ha más modult használunk.

Ahhoz, hogy bemutassuk, hogy egy Node.js Express szerver hogyan tud együttműködni egy SQL-adatbázissal, írjunk egy szkriptet, amely tárolja és megjeleníti a sütivel azonosított kliens által küldött üzeneteket. Az üzeneteket a kliens a HTTP POST módszerrel küldi el, a szerver válasza pedig a kliens által kért formátumtól függően JSON vagy HTML (sablon) formátumú lehet. Ez a lecke nem fogja részletezni a HTTP-módszerek, a sütik és a sablonok használatát. Az itt bemutatott kódrészletek feltételezik, hogy már van egy Node.js Express szerver, ahol ezek a szolgáltatások már be vannak állítva és elérhetőek.

A kliens által küldött üzenetek tárolásának legegyszerűbb módja, ha egy globális tömbben tároljuk őket, ahol minden korábban elküldött üzenethez egy egyedi azonosító kulcs tartozik kliensenként. Ezt a kulcsot sütiként lehet elküldeni a kliensnek, amelyet a szerver a jövőbeni kéréseknél bemutat a korábbi üzenetek lekérdezésére.

Ennek a megközelítésnek azonban van egy gyenge pontja: mivel az üzenetek csak egy globális tömbben tárolódnak, az összes üzenet elvész, amikor az aktuális szerver-munkamenet megszűnik. Az adatbázisokkal való munkának éppen ez az egyik előnye, hogy az adatok tartósan tárolódnak, és nem vesznek el, ha a szerver újraindul.

Az index.js fájlt használva a szerver fő szkriptjeként, beépíthetjük az sqlite3 modult és megadhatjuk az adatbázisként szolgáló fájlt az alábbiak szerint:

Ha még nem létezik, a messages.sqlite3 fájl ugyanabban a mappában jön létre, mint az index.js fájl. Ebben az egyetlen fájlban tárolódik az összes struktúra és a hozzájuk tartozó adatok. A szkriptben végrehajtott összes adatbázis-műveletet a db konstans fogja közvetíteni, amely a messages.sqlite3 fájlt megnyitó új sqlite3 objektum neve.

Addig nem lehet adatokat beszúrni az adatbázisba, amíg legalább egy tábla létre nem jön. A táblák létrehozása a CREATE TABLE utasítással történik:

A db.run() metódus az SQL-utasítások végrehajtására szolgál az adatbázisban. Maga az utasítás a metódus paramétereként íródik. Bár az SQL-állításoknak pontosvesszővel kell végződniük, amikor egy parancssori feldolgozóba írjuk be őket, a pontosvessző a programban paraméterként átadott kijelentésekben opcionális.

Mivel a run metódus minden alkalommal végrehajtásra kerül, amikor a szkriptet a node index.js segítségével hajtjuk végre, az SQL utasítás tartalmazza a IF NOT EXISTS feltételes záradékot, hogy elkerüljük a hibákat a jövőbeli végrehajtások során, ha a messages tábla már létezik.

A messages táblát a következő mezők alkotják: id, uuid és message. Az id mező egy egyedi egész szám, amely a táblázat minden egyes bejegyzésének azonosítására szolgál, ezért PRIMARY KEY mezőként van létrehozva. Az elsődleges kulcsok értéke nem lehet null, és ugyanabban a táblában nem lehet két azonos elsődleges kulcs. Ezért szinte minden SQL-táblának van elsődleges kulcsa a tábla tartalmának nyomonkövetése érdekében. Bár lehetőség van arra, hogy egy új rekord elsődleges kulcsának értékét explicit módon válasszuk ki (feltéve, hogy még nem létezik a táblában), célszerű, ha a kulcs automatikusan generálódik. Erre a célra az id mezőben található AUTOINCREMENT jelzőt használjuk.

Az uuid és az message mezők az ügyfél azonosítóját, illetve az üzenet tartalmát tárolják. A CHAR(36) típusú mező rögzített hosszúságú és 36 karakterből áll, a TEXT típusú mező pedig tetszőleges hosszúságú szövegeket tárol.

Példánk szerverének fő funkciója az üzenetek tárolása, amelyek az őket küldő klienshez kapcsolódnak. A kliens az üzenetet a HTTP POST módszerrel küldött kérés törzsében található message mezőben küldi el. Az ügyfél azonosítója egy uuid nevű sütiben található. Ezen információk birtokában megírhatjuk az Express utat az új üzenetek adatbázisba való beillesztéséhez:

Ezúttal az db.run() módszer végrehajt egy beszúró utasítást, de figyeljük meg, hogy a uuid és a req.body.message nem íródik közvetlenül az utasítás sorába. Ehelyett kérdőjelek kerültek az értékek helyére. Minden kérdőjel megfelel egy paraméternek, amely az SQL utasítást követi a db.run() metódusban.

A kérdőjelek placeholderként való használata az adatbázisban végrehajtott utasításban megkönnyíti az SQLite számára, hogy különbséget tegyen az utasítás statikus elemei és a változó adatok között. Ez a stratégia lehetővé teszi az SQLite számára, hogy az utasítás részét képező változó tartalmát feloldja (escape) vagy szanálja (sanitize), ezzel megelőzve az SQL injenction-nek nevezett gyakori biztonsági rést. Ebben a támadásban a rosszindulatú felhasználók SQL utasításokat illesztenek a változó adatokba, abban a reményben, hogy az utasítások véletlenül végrehajtásra kerülnek; a szanálás meghiúsítja a támadást az adatokban lévő veszélyes karakterek letiltásával.

Ahogy a mintakódban látható, a szándékunk az, hogy ugyanazt az utat használjuk az új üzenetek adatbázisba való beillesztésére és a korábban elküldött üzenetek listájának létrehozására. A db.all() metódus visszaadja a táblázatban lévő összes olyan bejegyzés gyűjteményét, amely megfelel a lekérdezésben meghatározott kritériumoknak.

A db.run() által végrehajtott utasításokkal ellentétben a db.all() rekordlistákat generál, amelyeket az utolsó paraméterben megadott nyílfüggvény kezel:

Ez a függvény viszont két paramétert vesz fel: az err és a rows paramétereket. Az err paramétert akkor használjuk, ha olyan hiba lép fel, amely megakadályozza a lekérdezés végrehajtását. Siker esetén az összes rekord elérhető a rows tömbben, ahol minden elem egy objektum, amely a táblázat egyetlen rekordjának felel meg. Ennek az objektumnak a tulajdonságai megfelelnek a lekérdezésben megadott mezőneveknek: uuid és message.

A rows tömb egy JavaScript adatszerkezet. Mint ilyen, válaszok generálására használható az Express által biztosított módszerekkel, mint például a res.json() és a res.render(). Egy EJS sablonon belül megjelenítve egy hagyományos ciklus az összes rekordot kilistázhatja:

Ahelyett, hogy a rows tömböt töltenénk meg a lekérdezés által visszaadott összes rekorddal, bizonyos esetekben kényelmesebb lehet minden rekordot külön-külön kezelni a db.each() metódussal. A db.each() metódus szintaxisa hasonló a db.all() metóduséhoz, de az (err, row) ⇒ {} paraméter row paramétere egyszerre csak egyetlen rekordra illeszkedik.

A kliensünk a szerveren még csak üzeneteket tud hozzáadni és lekérdezni. Mivel a kliens most már ismeri a korábban elküldött üzenetek id-jét, implementálhatunk egy függvényt egy adott rekord módosítására. A módosított üzenetet szintén elküldhetjük egy HTTP POST módszerrel készült útra, de ezúttal egy paraméterrel, hogy a kliens által a kérés útvonalában megadott id-t elkapjuk:

Ez az út demonstrálja, hogy hogyan használjuk az UPDATE és a WHERE záradékokat egy meglévő rekord módosítására. Fontos különbség az előző példákhoz képest a named parameters (nevesített paraméterek) használata, ahol az értékeket egyetlen objektumba (param) gyűjtjük és átadjuk a db.run() metódusnak ahelyett, hogy minden egyes értéket egymagában adnánk meg. Ebben az esetben a mezőnevek (amelyek előtt $ áll) az objektum tulajdonságai. A névvel ellátott paraméterek lehetővé teszik a mezőnevek ($ előtaggal) placeholderként való használatát kérdőjelek helyett.

A példában szereplőhöz hasonló utasítás nem okoz semmilyen módosítást az adatbázisban, ha a WHERE záradék által meghatározott feltétel nem felel meg a tábla valamelyik rekordjának. Annak kiértékelésére, hogy az utasítás módosított-e bármilyen rekordot, egy visszahívási (callback) függvényt használhatunk a db.run() metódus utolsó paramétereként. A függvényen belül a megváltozott rekordok száma lekérdezhető a this.changes függvényből. Jegyezzük meg, hogy ebben az esetben nem használhatók nyílfüggvények, mert csak a function(){} formájú szabályos függvények definiálják a this objektumot.

Egy rekord eltávolítása nagyon hasonló a módosításához. Például továbbra is használhatjuk az :id paramétert a törlendő üzenet azonosítására, de ezúttal egy olyan úton, amelyet a kliens HTTP DELETE módszere hív meg:

A rekordok törlése egy táblából a DELETE FROM záradékkal történt. Ismét a callback függvényt használtuk annak kiértékelésére, hogy hány bejegyzést távolítottunk el a táblából.

A definiálás után az db objektumra bármikor lehet hivatkozni a szkript végrehajtása során, mivel az adatbázisfájl az aktuális munkamenet alatt nyitva marad. Nem szokás az adatbázist bezárni a szkript futása közben.

Az adatbázis bezárására szolgáló függvény azonban hasznos lehet, hogy elkerüljük az adatbázis hirtelen bezárását, amikor a szerverfolyamat befejeződik. Bár valószínűtlen, az adatbázis hirtelen leállítása inkozisztenciákat eredményezhet, ha a memórián belüli adatok még nem lettek rögzítve a fájlban. Például adatvesztéssel járó hirtelen adatbázislezárás következhet be, ha a szkriptet a felhasználó a Ctrl+C billentyűkombináció megnyomásával fejezi be.

Az imént ismertetett Ctrl+C esetében a process.on() metódus képes az operációs rendszer által küldött jeleket elfogni és végrehajtani az adatbázis és a szerver szabályos leállítását:

A Ctrl+C parancsikon meghívja a SIGINT operációs rendszer-jelet, amely a terminálon lévő előtérben lévő programot befejezi. A SIGINT jel fogadásakor a rendszer a folyamat befejezése előtt meghívja a callback függvényt (a process.on() metódus utolsó paramétere). A callback függvényen belül bármilyen takarító kódot elhelyezhetünk, különösen a db.close() metódust az adatbázis bezárására és a server.close() metódust, amely elegánsan zárja be magát az Express példányt.