er et ACID-kompatibelt relationsdatabasestyringssystem, indeholdt i et relativt lille bibliotek skrevet i C
masse SQLite-udviklere er ved at udvikle et projekt, der skal implementeres evnen til at kompilere biblioteket til en mellemliggende WebAssembly-kode som kan køres i en webbrowser og er velegnet til at organisere arbejdet med databasen fra webapplikationer i JavaScript-sproget.
Målet af projektet er at levere et funktionelt JavaScript-link der er identisk i funktionalitet med SQLite API. Webudviklere er forsynet med en objektorienteret grænseflade på højt niveau til at arbejde med data i stil med sql.js eller Node.js, der omslutter en lav-niveau C API og en API baseret på Web Worker-mekanismen, der gør det muligt at skabe asynkron controllere, der kører på separate tråde.
For at skjule kompleksiteten ved at tråde over den Web Worker-baserede API, En variant af programmeringsgrænsefladen baseret på mekanismen Løfte.
De data, som webapplikationer gemmer i WASM-versionen af SQLite, kan lokaliseres inden for den aktuelle session (tabt efter genindlæsning af siden) eller bevares på klientsiden (vedvarer på tværs af sessioner).
Til permanent lagring er backends blevet forberedt til at lægge data på et lokalt filsystem ved hjælp af OPFS (Origin-Private FileSystem, udvidelse til File System Access API, som i øjeblikket kun er tilgængelig i WebKit- og Chromium-baserede browsere) og browserens lokale lagring baseret på window.localStorage og window.sessionStorage API'erne.
Når du bruger localStorage/sessionStorage, mappes dataene til de relevante nøgle-/værdilagre, mens der ved brug af OPFS er to muligheder: simulering af en virtuel FS ved hjælp af WASMFS og en separat sqlite3_vfs-implementering, der tilbyder et SQLite-baseret VFS-lag. i OPFS .
Emscripten-kompileren bruges til at bygge SQLite i en WASM-repræsentation. Resultatet er sqlite3.js- og sqlite3.wasm-filer, som du kan inkludere i dit JavaScript-projekt (HTML- og JavaScript-eksempel).
af de specifikke mål af dette projekt er nævnt:
Medmindre det er angivet i ikke-målene, skal du levere en mere eller mindre komplet indpakning af funktioner til sqlite3 C API, i det omfang WASM's funktionsparitet med C tillader det. Faktisk skal du som minimum levere følgende API'er.
- Bind et lavniveau sqlite3 API, der er så tæt på native som muligt med hensyn til brug.
- En højere niveau OO API, mere som sql.js og node.js stilimplementeringer.
- En arbejderbaseret API, der kommunikerer med ovenstående API'er gennem medarbejdermeddelelser. Dette er designet til at blive brugt på hovedtråden med API'er på lavere niveau installeret på en arbejdertråd og kommunikere med dem via arbejdermeddelelser.
- En Promise-baseret variant af Worker API, der fuldstændigt skjuler brugerens inter-thread kommunikationsaspekter.
- I det omfang det er muligt, understøtter klientsiden persistent lagring ved hjælp af tilgængelige JS API'er. På tidspunktet for denne skrivning inkluderer det Source Private File System (OPFS) og (meget begrænset) lagring via backendsene window.localStorage og .window.sessionStorage
Hvad angår ikke-specifikke mål:
- Da WASM er en webcentreret teknologi, og UTF-8 er kongen af kodninger i det område, er der ingen aktuelle planer om at understøtte UTF3-relaterede sqlite16 API'er.
- Mens understøttelse af WASM-runtime uden for browseren er udbredt, er dette projekt i øjeblikket (slutningen af 2022) kun fokuseret på browsermål. Selvom web-relaterede implementeringsdetaljer har forrang, og API's JavaScript-komponenter fokuserer specifikt på browserklienter, "bør" WASM-modulet på lavere niveau fungere i ikke-web-WASM-miljøer.
- Kompatibilitet med gamle eller nicheplatforme. WASM er designet til et moderne web og kræver moderne platforme. Tilsvarende vil forældede sqlite3-biblioteksindstillinger blive fjernet helt fra WASM-grænsefladen.
Koden til WebAssembly-support er blevet tilføjet til projektets hovedlager. I modsætning til WebSQL API, som er baseret på SQLite, er WASM SQLite fuldstændig isoleret fra browseren og påvirker ikke dens sikkerhed (Google besluttede at droppe understøttelsen af WebSQL i Chrome efter adskillige sårbarheder i SQLite, der kunne udnyttes gennem WebSQL til at angribe Navigatoren ).
endelig hvis du er det interesseret i at lære mere om det, kan du kontrollere detaljerne I det følgende link.