SQLite

SQLite е отворена, многоплатформена, безплатна и малка библиотека C, която изпълнява самостоятелен, интегриращ се, транзакционен, без сървър и нулево конфигуриран SQL база данни. Това е най-използваният в света SQL сървър на база данни.

Основните функции включват поддръжка на изолирани, атомни, трайни и последователни транзакции, SQL92 изпълнение, бази данни могат да бъдат споделяни свободно между компютри, поддържа бази данни до 2 терабайта, поддръжка на gigabyte размери и струни, малък код отпечатък, както и лесен за използване и много прост API (Application Programming Interface).

Освен това SQLite не изисква първоначална конфигурация или по-нататъшна администрация, позволява на разработчиците да съхраняват пълна база данни в един и същ платформен диск, който е идеален за използване на файлови формати на приложения, няма външни зависимости, в TCL (Command Language на инструмента) свързвания и обширна документация.

Връзките за множество други езици за програмиране се предлагат отделно. Неговият изходен код е добре коментиран и идва със самостоятелен клиент CLI (интерфейс на командния ред), който е проектиран от отместването, който ще се използва за администриране на SQLite бази данни.

SQLite базата данни може да се използва за всякакви цели, лични или търговски. Предложените приложения за SQLite включват база данни за притурки, база данни на уебсайтове, stand-in за предприятие RDBMS (релационна система за управление на бази данни), както и формат на файла на приложението.

Разпределението на SQLite идва със самостоятелна програма за достъп до командния ред (sqlite), която може да се използва за администриране на SQLite база данни и която служи като пример за използване на SQLite библиотеката. Той е написан изцяло на програмния език ANSI-C.

Поддържаните настолни операционни системи включват GNU / Linux, Mac OS X и Microsoft Windows. Поддържаните мобилни операционни системи включват Android и iOS. Той е бил успешно тестван както с 32-битови, така и 64-битови хардуерни платформи и е лесно преносим към други операционни системи.

Какво ново в това издание: р>

• Акценти от това издание включват поддръжка на UPSERT стил PostgreSQL и подобрена производителност, особено за заявки ORDER BY LIMIT.

Какво е новото във версията:

• Възползвайте се от възможностите за запис на атомни файлове във файловата система F2FS, когато са налични, за значително намаляване на режийните разходи. Това в момента изисква опцията за компилиране на SQLITE_ENABLE_BATCH_ATOMIC_WRITE.
• Позволете на командите ATTACH и DETACH да работят вътре в транзакцията.
• Позволете WITHOUT ROWID виртуалните таблици да бъдат записвани, ако PRIMARY KEY съдържа точно една колона.
• Файлът "fsync ()" , който се получава, след като заглавката е написана в WAL нулиране сега използва настройките за синхронизация за контролни пунктове. Това означава, че ще се използва "fullfsync" на Mac, ако PRAGMA checkpoint_fullfsync е включен.
• Функцията sqlite3_sourceid () се опитва да открие дали изходният код е бил променен от това, което е включено в контрола на версията и ако има промени, последните четири знака на хеш версията са показани като "alt1" или "alt2". Целта е да се открият случайни и / или невнимателни редакции. Фалшификаторът може да наруши тази функция.
• Подобрено декоиране на имената на колоните за изразите CREATE TABLE AS с обобщена заявка в дясната страна.
• По-малко "stat ()" системни повиквания, издадени от Unix VFS.
• Усъвършенства оптимизацията LIKE, така че да работи с клауза ESCAPE.
• Подобрени PRAGMA integrity_check и PRAGMA quick_check, за да открият неясна корупция на ред, която преди това им липсваше. Също така актуализирайте и двете pragmas, така че те да връщат грешен текст, а не SQLITE_CORRUPT, когато срещат корупция в записите.
• Планиращият за заявки предпочита да внедри под-заявки от SUB-клауза, като използва ко-рутинни процедури, а използва оптимизацията на изравняване на заявки. Поддръжката за използването на съ-рутинни процедури за подчинените вече не може да бъде деактивирана.
• Прехвърлете информация за виртуалните таблици за метода xBestIndex.
• Усъвършенствана е виртуалната таблица на CSV, така че да приеме последния ред от входа, ако липсва последният символ от новата линия.
• Премахнете рядко използваната "драско" разпределител на паметта. Заменете го с настройката за конфигурация на SQLITE_CONFIG_SMALL_MALLOC, която дава на SQLite намек, че когато е възможно, трябва да се избягват големи разпределения на паметта.
• Добавена е виртуалната таблица на рояка към съществуващото разширение на виртуална маса на съюз.
• Добавена е виртуалната таблица sqlite_dbpage за осигуряване на директен достъп до страниците на файла на базата данни. Изходният код е вграден в сливането и се активира с помощта на опцията -SQLQL_START_DBPAGE_VTAB за компилиране.
• Добавете нов тип виртуална таблица fts5vocab - "инстанция" - който осигурява директен достъп до пълен текст FTS5 на най-ниското възможно ниво.
• Премахване на обаждане до rand_s () в Windows VFS, тъй като причинява проблеми в Firefox на някои по-стари лаптопи.
• Изходният код src / shell.c към корпуса на командния ред вече не е под контрола на версията. Този файл се генерира като част от процеса на създаване.
• Различните микрооптимизации намаляват използването на процесора с около 2,1%.
• Поправки на програмни грешки:
• Коригирайте дефектираното твърдение (), открито от OSSFuzz. Билет cb91bf4290c211d
• Коригирайте неизвестното изтичане на памет в sqlite3_result_pointer (). Билет 7486aa54b968e9b
• Избягвайте евентуална грешка след употреба, като отложите нулирането на схемите, докато не приключи изпълнението на плана за заявки. Билет be436a7f4587ce5
• Използвайте само индекси за изразяване, за да оптимизирате ORDER BY или GROUP BY, ако COLLATE е правилно. Билет e20dd54ab0e4383
• Коригирайте грешка в твърдението, което се появява, когато изразът в индекс на израз е наистина постоянен. Билет aa98619ad08ddca
• Поправете грешка в твърдението, което може да възникне след PRAGMA reverse_unordered_selects. Билет cb91bf4290c211d
• Решете сегфаут, който може да възникне за запитвания, които използват функции, оценени в таблица, в под-заявка IN или EXISTS. Билет b899b6042f97f5
• Коригирайте проблем с препълване на потенциално цяло число, когато компилирате конкретен ужасен общ израз на таблица. Това беше друг проблем, открит от OSSFuzz. Настаняване 6ee8cb6ae5.
• Коригирайте потенциално изчерпано четене при запитване към файл с корумпирана база данни, проблем, открит от Натали Силванович на Google Project Zero. Настаняване 04925dee41a21f.

Какво е новото във версия 3.20.1:

• Версията на версия 3.20.1 пластир променя два реда код в интерфейса sqlite3_result_pointer (), за да се определи рядко изтичане на памет.

Какво е новото във версия 3.9.2:

• SQLite версия 3.9.2 е издание на пластир, закрепващо две неясни бъгове.

Какво е новото във версия 3.8.9:

• Нови функции в тази версия включват командата PRAGMA index_xinfo, интерфейсът sqlite3_status64 () и командата ".dbinfo" на обвивката на командния ред.

Какво е новото във версия 3.8.8.2:

• Освобождаването на кръпка от 3.8.8.2 поправя един малък проблем: Той гарантира, че операцията sqlite3_wal_checkpoint (TRUNCATE) винаги ще прекъсне регистрационния дневник, дори ако дневникът вече е бил нулиран и не съдържа ново съдържание. Не е ясно дали това е корекция на грешки или нова функция.
• Нещо като това обикновено влиза в следващото редовно планирано издаване, но известен потребител на SQLite се нуждае от бърза смяна, така че ние се радваме да го избухнем по този начин.
• Няма причина да надстройвате, освен ако всъщност не се нуждаете от подобрено поведение на sqlite3_wal_checkpoint (TRUNCATE).

Какво е новото във версия 3.8.8.1:

• Коригирайте грешка в логиката за сортиране, налична след версия 3.8.4, която може да доведе до появата на изход в грешна последователност при заявки, съдържащи клауза ORDER BY, клауза LIMIT и които имат около 60 или повече колони в зададеният резултат. Билет f97c4637102a3ae72b79.
• SQLITE_SOURCE_ID: "2015-01-20 16:51:25 f73337e3e289915a76ca96e7a05a1a8d4e890d55"
• SHA1 за sqlite3.c: 33987fb50dcc09f1429a653d6b47672f5a96f19e

Какво е новото във версия 3.8.8:

• Нови функции:
• Добавена е командата PRAGMA data_version, която може да се използва за определяне дали файлът на базата данни е бил променен от друг процес.
• Добавена е опцията SQLITE_CHECKPOINT_TRUNCATE към интерфейса sqlite3_wal_checkpoint_v2 (), със съответните подобрения на PRAGMA wal_checkpoint.
• Добавен е интерфейлът sqlite3_stmt_scanstatus (), наличен само когато е компилиран с SQLITE_ENABLE_STMT_SCANSTATUS.
• Слоят sqlite3_table_column_metadata () е подобрен, за да работи правилно на WITHOUT ROWID таблици и да провери наличието на таблица, ако параметърът за името на колоната е NULL. Интерфейсът вече е включен в подразбиране, без да е необходима опцията за компилиране на SQLITE_ENABLE_COLUMN_METADATA.
• Добавена е опцията за компилиране на SQLITE_ENABLE_API_ARMOR.
• Добавена е опцията за компилиране на SQLITE_REVERSE_UNORDERED_SELECTS.
• Добавена е опцията за компилиране на SQLITE_SORTER_PMASZ и опцията за стартиране на SQLITE_CONFIG_PMASZ.
• Добавена е опцията SQLITE_CONFIG_PCACHE_HDRSZ към sqlite3_config (), която улеснява приложенията да определят подходящото количество памет за използване с SQLITE_CONFIG_PAGECACHE.
• Броят на редовете в клаузата VALUES вече не е ограничен от SQLITE_LIMIT_COMPOUND_SELECT.
• Добавя се разширението за зареждане eval.c, което изпълнява функция SQL (), която ще рекурсивно преценява SQL.
• Подобрения на ефективността:
• Намалете броя на операциите memcpy (), участващи в балансирането на b-tree, за 3.2% цялостно повишаване на производителността.
• Подобрения в оценките на разходите за оптимизирането на сканирането.
• Автоматичното оптимизиране на индексирането вече може да генерира частичен индекс, ако това е подходящо.
• Поправки на програмни грешки:
• Уверете се, че трайността е след загуба на мощност с "PRAGMA journal_mode = TRUNCATE", като извикате fsync () веднага след отрязването на журналния файл.
• Планинтът за заявки вече разпознава, че всяка колона в дясната таблица на LEFT JOIN може да бъде NULL, дори ако тази колона има ограничение NOT NULL. Избягвайте да се опитвате да оптимизирате тестовете за NULL в тези случаи. Прикрепвам за билет 6f2222d550f5b0ee7ed.
• Уверете се, че ORDER BY поставя редове във възходящ ред, дори ако операторът DISTINCT се изпълнява с низходящ индекс. Прикрепвам за билет c5ea805691bfc4204b1cb9e.
• Коригирайте състезания за данни, които могат да се появят при натоварване, когато работите с много нишки в споделен кеш режим, където някои от нишките отварят и затварят връзки.
• Прикрепете неясни бъгове за катастрофата, намерени от американската размита лопатка. Билет a59ae93ee990a55.
• Обърнете внимание на грешка в GCC оптимизатора (за gcc 4.2.1 на MacOS 10.7), която е причинила разширението R-Tree да изчисли неправилни резултати при компилирането с -O3.
• Други промени:
• Деактивирайте използването на rutine на strchrnul () C библиотеката, освен ако не е специално разрешена с помощта на опцията -DHAVE_STRCHRNULL за компилиране.
• Подобрения в ефективността и точността на вероятностите (), вероятно () и невероятните () функции на SQL.
• SQLITE_SOURCE_ID: "2015-01-16 12:08:06 7d68a42face3ab14ed88407d4331872f5b243fdf"
• SHA1 за sqlite3.c: 91aea4cc722371d58aae3d22e94d2a4165276905

Какво е новото във версия 3.8.7.4:

• Тази корекция на версиите добавя допълнителен mutex, който се изисква от промените в кръпка 3.8.7.3, но е случайно пропуснат. Mutex не се изисква от нито един от вътрешните SQLite тестове, но Firefox се срива без него. Бяха добавени тестови случаи, за да се гарантира, че никога не се пропуска мютекс.

Какво е новото във версия 3.8.7.3:

• Отстраняване на грешки: Уверете се, че кешираните обекти KeyInfo (вътрешна абстракция, която не се вижда от приложението) не изчезват, когато работите в споделен кеш памет и често затварят и отварят някои връзки на базата данни, докато оставят други връзки на базата данни в същия споделен кеш непрекъснато. Билет e4a18565a36884b00edf.
• Отстраняване на грешки: Разберете, че колоната в дясната таблица на LEFT JOIN може да бъде NULL дори ако колоната има ограничение NOT NULL. Не прилагайте оптимизации, които предполагат, че колоната никога не е NULL. Билет 6f2222d550f5b0ee7ed.
• SQLITE_SOURCE_ID: "2014-12-05 22:29:24 647e77e853e81a5effeb4c33477910400a67ba86"
• SHA1 за sqlite3.c: 3ad2f5ba3a4a3e3e51a1dac9fda9224b359f0261

Какво е новото във версия 3.8.7.2:

• Основната причина за това издание е да подобри командата ROLLBACK, така че да позволява текущите заявки в същата връзка да продължат да се изпълняват, докато ROLLBACK не променя схемата. Във всички предишни версии на SQLite ROLLBACK би довел до спиране на задаваните заявки и връщане на SQLITE_ABORT или SQLITE_ABORT_ROLLBACK. Чакащите заявки продължават да се прекратяват, ако ROLLBACK променя схемата на базата данни, а от тази версия на кръпката, заявките могат да продължат да се показват, ако схемата не е модифицирана.
• В допълнение към подобрението ROLLBACK тази версия на корекцията включва и корекции за три неясни грешки.

Какво е новото във версия 3.8.7.1:

• Основната причина за това съобщение за отстраняване на бъгове е да се отговори на проблем с актуализирането на стойностите на полетата в края на таблицата, добавени чрез ALTER TABLE ADD COLUMN. Този проблем първо се появи в изданието 3.8.7.
• Друго незначително раздразнение в изданието 3.8.7 бе фактът, че устройството Android се опита да използва функцията strchrnul () от стандартната библиотека C, но тази функция не е налице в Android. Настройките на Android трябваше да добавят -DHAVE_STRCHRNUL = 0, за да разрешат проблема. Този кръпка поправя така, че Android Build да работи сега без никакви промени.
• Действието на PRAGMA journal_mode = TRUNCATE е подобрено, така че да се припокрие fsync () след съкращаване на дневника, когато PRAGMA synchronic = FULL. Това помага да се запази трайността на транзакциите в случай на загуба на мощност, възникваща скоро след извършване на ангажимента.
• И накрая, бяха отстранени няколко отдавнашни и неясни проблеми, свързани с пускането на UPDATE и DELETE на VIEWs.

Какво е новото във версия 3.8.7:

• Повечето от промените от предишната версия са били микро оптимизации, създадени, за да помогнат SQLite да работи малко по-бързо. Всяка отделна оптимизация има несъизмеримо малко въздействие върху производителността. Но подобренията се увеличават. Измерено при добре дефинирано работно натоварване (което разработчиците на SQLite използват като прокси за типично натоварване на приложенията), използвайки cachegrind на Linux и компилирано с gcc 4.8.1 и -Os на x64 linux, текущото съобщение прави над 20% повече работа за същия брой CPU цикли в сравнение с предишното съобщение. Cachegrind не е реален процесор, а работното натоварване, използвано за измерване, е само прокси. Така че ефективността ви може да варира. Очакваме да видим около половината от измереното и отчетено подобрение в приложенията в реалния свят. 10% е по-малко от 20%, но все още е доста добра, мислим.
• Това издание включва нов набор от C-езикови интерфейси, които имат неподписани 64-битови, вместо подписани 32-битови параметри за дължина. Новите приложни програмни интерфейси (API) не предлагат нови възможности. Но те улесняват писането на приложения, които са по-устойчиви на уязвимости при препълване на цяло число.
• Тази версия също така включва нов сортировач, който може да използва множество нишки, за да помогне с големи операции за сортиране. (Операциите за сортиране понякога се изискват за изпълнение на клаузите ORDER BY и / или GROUP BY и почти винаги се изискват за CREATE INDEX.) Сортировачът с множество нишки е изключен по подразбиране и трябва да бъде активиран с помощта на командата PRAGMA нишки SQL. Имайте предвид, че многоредовият сортировач осигурява по-бърза ефективност в реално време за големи сортове, но също така използва повече цикли на процесора и повече енергия.

Какво е новото във версия 3.8.3.1:

• SQLite версия 3.8.3.1 поправя грешка в версии 3.8.1, 3.8.2 и 3.8.3, които могат да причинят заличаване на валидни редове. Препоръчва се надстройване от тези версии.
• Проблемът възниква само ако SQLite се компилира с опциите за компилиране SQLITE_ENABLE_STAT3 или SQLITE_ENABLE_STAT4. В този случай, ако дадена заявка има клауза WHERE, която съдържа изрази като тази:
• WHERE (expr1 ИЛИ expr2 OR ... ИЛИ exprN) И колоната НЕ Е НУЛНА
• Когато всички от expr1 чрез exprN са подходящи за използване от индекси, тогава по време на планирането на заявки SQLite може погрешно да е преобразувал термина "колона IS NOT NULL" в "column & gt; NULL". Но последният термин никога не е вярно и затова заявката няма да върне никакви редове.

Какво е новото във версия 3.8.3:

• Добавена е поддръжка за общи изрази на таблици и клаузата WITH.
• Добавена е функцията printf () SQL.
• Добавя SQLITE_DETERMINISTIC като допълнителен бит в 4-тия аргумент към sqlite3_create_function () и свързаните интерфейси, като предоставя на приложенията способността да създават нови функции, които могат да бъдат фактурирани от вътрешните вериги, когато имат постоянни аргументи.
• Добавете SQLITE_READONLY_DBMOVED код за грешка, върнат в началото на транзакция, за да покажете, че основният файл на базата данни е бил преименуван или изваден от под SQLite.
• Позволете произволни изрази, включително функционални повиквания и подсъобщения, в аргумента за име на файл, за да прикрепите.
• Позволете на клаузата VALUES да се използва навсякъде, където е валидно изявление SELECT.
• Поставете отново PRNG, използван от sqlite3_randomness (N, P), когато се извикате с N == 0. Автоматично презареждане след вилица () на Unix.
• Увеличете виртуалната таблица на spellfix1, така че да може да търси ефективно от rowid.
• Подобрения на ефективността.
• Подобрения в коментарите в байтовете на VDBE байт, когато се изпълнява EXPLAIN.
• Добавете директивата "% token_class" към генератора на анализа LEMON и го използвайте, за да опростите граматиката.
• Променете изходния код LEMON, за да избегнете повикване на функциите на C-библиотеката, които OpenBSD счита за опасни. (Напр. Спринт).
• Отстраняване на грешки: Във функцията за импортиране на команда CSV в командния ред не прекратете поле, когато в края на CRLN се появи избран двоен цитат.
• SQLITE_SOURCE_ID: "2014-02-03 13:52:03 e816dd924619db5f766de6df74ea2194f3e3b538"
• SHA1 за sqlite3.c: 98a07da78f71b0275e8d9c510486877adc31dbee