უკან დაბრუნება
წინადადება SQLite-ისთვის: ერთი პრაგმა ოთხი ცუდი ნაგულისხმევის გამოსასწორებლად
SiTech AI Team2 წთ. საკითხავი

წინადადება SQLite-ისთვის: ერთი პრაგმა ოთხი ცუდი ნაგულისხმევის გამოსასწორებლად

ბლოგპოსტის ავტორი ამტკიცებს, რომ SQLite-ის ნაგულისხმევი პარამეტრები — გამორთული foreign key-ები, მკაცრი ტიპიზაციის არარსებობა, მყისიერი SQLITE_BUSY შეცდომები და WAL-ის გარეშე მუშაობა — უნდა შეიცვალოს Rust-ის სტილის edition-პრაგმით.

SQLite ლოკალური მონაცემების შენახვის ინდუსტრიული სტანდარტია და, ტრადიციული მონაცემთა ბაზის სერვერისგან განსხვავებით, ბიბლიოთეკის სახით არსებული RDBMS-ია და არა ცალკე პროცესი, რაც აპლიკაციებს თვითკმარად ინახავს. თუმცა 15 ივლისს გამოქვეყნებულ პოსტში დეველოპერი Mort ამტკიცებს, რომ მისი ნაგულისხმევი პარამეტრები არასწორია და ძრავას სჭირდება განვითარების გზა ძველი პროგრამების გატეხვის გარეშე.

ოთხი ნაგულისხმევი, რომელსაც ავტორი შეცვლიდა

პირველია foreign key შეზღუდვები, რომლებსაც SQLite უგულებელყოფს, თუ PRAGMA foreign_keys = ON არ გაუშვებთ. ავტორის თქმით, ეს ერთადერთი RDBMS-ია, რომელიც მათ ნაგულისხმევად არ ამოწმებს, და ROWID-ების ხელახლა გამოყენების ტენდენცია შედეგებს აუარესებს: ჩამოკიდებული ბმული ჩუმად შეიძლება არასწორ მწკრივს მიუთითებდეს. მის მაგალითში წაშლილი მომხმარებლის დატოვებულ პოსტს იბარებს ახალი ანგარიში, რომელიც შემთხვევით იმავე ID-ს იღებს.

მეორე ტიპიზაციაა. INTEGER-ად გამოცხადებული სვეტი INTEGER affinity-ს იყენებს, ამიტომ რიცხვის მსგავსი ტექსტი რიცხვად ინახება, დანარჩენი კი — როგორც არის; შესაბამისად, ხანგრძლივობის სვეტში შეიძლება მოხვდეს სტრიქონი „Way too long, I mean come on“. ამას strict ცხრილები ასწორებს — INTEGER სვეტში TEXT-ის ჩასმა შეცდომას იწვევს — მაგრამ პრაგმა, რომელიც ყველა ცხრილს მკაცრს გახდის, არ არსებობს, ამიტომ სიტყვა ხელით უნდა დაამატოთ.

მესამე კონკურენტულობაა: SQLite ბევრ მკითხველს უშვებს, მაგრამ მხოლოდ ერთ მწერალს, და ნაგულისხმევად მეორე პროცესი, რომელიც ჩაწერის ბლოკირების აღებას ცდილობს, მყისიერად იღებს SQLITE_BUSY შეცდომას. ავტორს ურჩევნია ბლოკირების ლოდინი დროის ლიმიტამდე (PRAGMA busy_timeout = 5000) — პარამეტრი, რომელიც, მისი თქმით, რეალური კრაშების შემდეგ დაამატა.

წარმადობა და edition-ის წინადადება

მეოთხე წარმადობაა. Write-ahead ჟურნალი ნაგულისხმევად გამორთულია; PRAGMA journal_mode = WAL-ის ჩართვა უმეტეს შემთხვევაში ჩაწერას მკვეთრად აჩქარებს და PRAGMA synchronous = NORMAL-თან ერთად დისკის სინქრონიზაციების რაოდენობას მნიშვნელოვნად ამცირებს დაზიანების რისკის გარეშე. პოსტი დეტალებისთვის Sylvain Kerkour-ის სტატიას გვირჩევს.

ამ ყველაფრის უკუთავსებადობის დარღვევის გარეშე გამოსასწორებლად — რაც ნაგულისხმევი პარამეტრების შენარჩუნების ჩვეულ მიზეზად სახელდება — ავტორი ერთ „სუპერ პრაგმას“ სთავაზობს: PRAGMA edition = 2026, რომელიც foreign_keys = ON, busy_timeout = 5000, journal_mode = WAL და synchronous = NORMAL-ის ალიასი იქნება, strict ცხრილებით ნაგულისხმევად.

იდეა Rust-ის edition-ებიდან არის ნასესხები. ავტორის აზრით, წლის ნომრით edition ჯობია JavaScript-ის „use strict“-ის მსგავს მიდგომას, რადგან გონივრული ნაგულისხმევი პარამეტრები დროთა განმავლობაში იცვლება: თუ მომავალში WAL2-ის მსგავსი ჟურნალის ფორმატი მთავარ ტოტში მოხვდება, PRAGMA edition = 2034 მას დააყენებს. მკითხველი კომენტარში აღნიშნავს, რომ SQL 99 უკვე განსაზღვრავს ტიპის ალიასებს CREATE DOMAIN-ით.

SSiTech

SiTech — AI-გაძლიერებული ვებ დეველოპმენტი

ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.