It libSQL-projekt hat besocht in gabel te meitsjen fan 'e SQLite-database dy't rjochte is op iepen te wêzen foar dielname fan mienskipûntwikkelders en it befoarderjen fan ynnovaasje bûten de oarspronklike bedoeling fan SQLite. De reden jûn foar de foarke is it earder strikte belied fan SQLite om koade fan tredden te akseptearjen fan 'e mienskip as der ferlet is om ferbetteringen te befoarderjen. De koade foar de foarke wurdt ferspraat ûnder de MIT-lisinsje (SQLite is yn it publike domein).
De makkers fan 'e gabel binne fan doel om kompatibiliteit te behâlden mei de haad SQLite en itselde nivo fan kwaliteit te behâlden, de set fan testgefallen te hâlden en it stadichoan útwreidzjen as nije funksjes wurde tafoege. Om nije funksjonaliteit te ûntwikkeljen, wurdt foarsteld om de mooglikheid te jaan om de Rust-taal te brûken, mei it behâld fan it basisdiel yn 'e C-taal. Yn it gefal fan in feroaring yn it belied fan it haad SQLite-projekt oangeande de akseptaasje fan wizigingen, binne de libSQL-ûntwikkelders fan doel de opboude wizigingen oer te bringen nei it haadprojekt en mei te dwaan oan har ûntwikkeling.
Under de ideeën foar in mooglike útwreiding fan 'e funksjonaliteit fan SQLite wurde neamd:
- Yntegraasje fan ark foar it bouwen fan ferdielde databases dy't wurkje op it nivo fan 'e bibleteek sels, en net troch de replikaasje fan feroaringen yn it bestânsysteem (LiteFS), en sûnder de ûntwikkeling fan in apart produkt (dqlite, rqlite, ChiselStore).
- Optimalisaasje foar it brûken fan asynchrone API's, lykas de io_uring-ynterface levere troch de Linux-kernel.
- De mooglikheid om SQLite yn 'e Linux kernel te brûken, fergelykber mei de stipe yn' e kernel fan 'e eBPF firtuele masine, foar situaasjes wêr't jo gegevenssets fan' e kernel moatte bewarje dy't net passe yn RAM.
- Stipe foar brûker-definieare funksjes skreaun yn elke programmeartaal en gearstald yn WebAssembly-tuskenkoade.
Boarne: opennet.ru