https://drive.google.com/file/d/1euSps6Tq6_E9o44XTEFV3JSY2PGt0N5N/view?usp=sharing

.1 +m1-5 \nm Design and Conceptions
.;1 +m1-5 Дизайн и концепции \nm
.^
Эта глава описывает базис для последующих глав, каждая из которых будет фокусироваться
на различных аспектах программирования для \nm.
Она аппелирует к вещам, которые должен знать программист, использующий \nm в своих приложениях.
Эти знания помогут понять не только программный интерфейс \nm, но так же его архитектуру
и реализацию независимо от языка программирования: все равно будет ли это родной для \nm С, толи
язык разработки скриптов. Вооруженный этими знаниями разработчик будет лучше подготовлен
для создания более быстрых и надежных приложений, избегающий потенциальных трудностей, связанных с
блокировками и неожиданными ошибками. Зная как \nm работает относительно кода разработчика,
можно быть более уверенным что задача решается с правильной начальной позиции.
.^
Нет нужды просматривать исходный код \nm, что бы понять тонкости его использования
равно как и нет нужды уметь программировать на C. Концепции и дизайн \nm очевидны и легки для использования.
Есть лишь несколько фактов, которые требуется знать.
Эта глава излагает главные концепции и компоненты, при помощи которых можно выстроить необходимый уровень понимания \nm.
Знание о работе программного интерфейса является ключем к пониманию \nm.
Таким образом, эта глава начинается со введения в програмный интерфейс, иллюстрирует его основные структуры,
его общий дизайн и его главные функции. Также уделяется внимание основным подсистемами \nm, играющим важную
роль в обработке запросов.
.^
Кроме знания какая функция выполняет какую работу, уделяется внимание тому, как программный интерфейс
функционирует в терминах транзакций. Все, включая базу данных \nm, рассматривается в контексте транзакций.
Затем приходится заглянуть ниже программного интрефейса, чтобы понять как транзакции выполняются в терминах
блокировок. Блокировки могут создавать трудности, если не понимать как они выполняются. Понимание
блокировок позволяет не только избегать потенциальных проблем конкуренции, но также оптимизировать выполняемые
запросы, контролируя как приложение использует блокировки.
.^
Наконец, требуется понимание того, как это все вместе используется для разработки приложений.
Последняя часть главы обсуждает все три темы - програмный интрефейс, транзакции и блокировки - вместе
и рассматривает различные примеры хорошего и плохого кода.
Там уточняются сценарии, которые могут приводить к трудностям и предоставляется некоторый взгляд,
позволяющих избегать их.
.^
Применяя все изложенное в правильном порядке, можно уверенно добиваться хороших результатов
вне зависимости от языка (все равно С или любой другой), на котором
используется программный интрефейс.



.2 +m1-5-1 The API
.;2 +m1-5-1 Программный интерфейс
.^
Функционально, программный интерфейс (иногда API: application program interface)
\nm можно разделить на две части: базовый программный интрефейс
и расшеренный.
Базовый интерфейс состоит из функций, которые используются для выполнения основных операций БД:
соединение с БД, выполнение операторов SQL и получения результатов. Кроме того, он содержит
дополнительные функции, которые полезны при выполнении таких задач, как форматирование строк,
управления операциями, отладка и обработка ошибок. Расширенный программный интерфейс предлагает
различные возможности для расширения \nm при помощи создания дополнений, определяемых пользователем,
которые интегрируются в \nm диалект языка SQL.

.3 The Principal Data Stuctures
.;3 Основные структуры данных
.^
Как объяснялось в главе
.;+m2-1
,
\nm состоит из нескольких компонент - парсера, лексического анализатора, виртуальной машины и так далее.
С точки зрения программиста, главными компонентами, о которых надо помнить,
являются соединения,
операторы, B-дерево и pager.
На рис.
.;+pic6-1
изображены взаимоотношения между перечисленными компонентами.
Эти объекты описывают три принципиальные вещи, которые необходимо знать про \nm,
что бы разрабатывать хорошие приложения: программный интерфейс, транзакции и блокировки.
Технически, B-дерево и pager не является частью программного интерфейса,
они находятся за его границами. Но они играют критическую роль в транзакциях
и блокировках. Далее, в этой секции и в секции 'Транзакции' вовлеченность
B-дерева и pager-а в транзакции и блокировки будет подробно исследована.
.; pager---

.b
.;-
\begin {figure}[h]
\includegraphics[width=1.00\textwidth]{./m6_pics/test0.png}
\caption{Модель объектов API языка С для SQLite}\label{pic6-1}
\end {figure}
.;-



.4 Connections and Statements
.;4 Соединения и Операторы
.^
Двумя фундаментальными структурами данных в програмном интерфейсе,
которые ассоциированы
с обработкой запросов, явдяются соединения и операторы.
В расширениях большинства языков для \nm можно увидеть объекты для соединений и
для операторов, которые используются для выполнения запросов.
В програмном интерфейсе для C эти структуры напрямую ссылаются на хендлеры $sqlite3$
и $sqlite3\_stmt$ соответственно.
Практически любое действие при помощи програмного интерфейса
выполняется с использованием этих двух структур.
.^

Структура оединение предоставляет одиночное соединение с БД равно как и контекст для
одиночной транзакции. Операторы создаются на основе соединений.
Таким образом, для каждого оператора существует соединение, ассоциированное с ним.
Структура оператор представляет собой одиночный откомпилированный оператор SQL.
С точки зрения разработчиков \nm, оператор представляется в форме байт кода VDBE -
программы для выполнения оператора SQL.
.x +vdbe байт кода VDBE
Структура содержит все необходимое для выполнения оператора SQL.
Она содержит ресурсы для запоминания состояния программы VDBE по мере выполнения,
.; as it executed in a stepwise fashion
курсор B -дерева, указывающего на запись диска, равно как и другие вещи,
такие как связанные параметры.
Связанные параметры будут обсуждаться позже в секции 'Связывание параметров'.
Хотя команды содержат множество различных вещей, о них можно думать как о курсоре, используемом
в циклах для прохода через набор записей результата работы оператора SQL или
как о хендлере, ссылающемся на оператор SQL.
.4 The B-tree and Pager
.^
Каждое соединение может имет несколько объектов БД - одна главная
БД с последующими присоединенными БД. Каждый объект БД имеет один объект
называемый B-дерево, которое в свою очередь, имеет один объект называемый pager.
.^
Операторы используют B-дерево и pager что бы читать данные из БД и писать в БД данные.
Операторы, которые читают БД, делают это последовательно через B-дерево, используя курсоры.
Курсоры последовательно просматривают записи, которые хранятся в виде страниц.
Так как курсор проходит по записям, то ему также приходится проходить через страницы.
Для обеспечения доступа курсора к странице, она должна быть предварительно загружена
из диска в оперативную память. Эту работу выполняет pager. Когда B-дерево
нуждается в конкретной странице из БД, оно обращается к pager-у, чтобы он
прочитал требуемую страницу с диска. Затем pager загружает страницу в кэш страниц, играющий роль
буфера памяти. Как только страница оказывается в кэше страниц, B-дерево и связанный с ним
курсор могут добраться к записями внутри страницы.
.^
Если курсор меняет данные страницы, то pager должен предпринять меры чтобы
сохранить исходную страницу для выполнения отката транзакции.
То есть, pager ответственен за чтение из БД, запись в БД,
поддержание кэша памяти или страниц
и управление транзакциями. В дополнение к этому, он управляет блокировками и восстановлением
после краха. Все это позднее раскрывается в разделе 'Транзакции'.

.^
Вообще говоря, нужно знать два факта про соединения и транзакции.
Первый - любою операцию над БД соединение всегда выполняет в транзакции.
Второй - соединение никогда не имеет более одной транзакции в один момент времени.
Это означает, что все операторы, построенные для данного соединения,
выполняются в одном и том же контексте
транзакции.
Требование выполнить более чем один оператор в разных транзакциях влечет необходимость
использовать несколько соединений, одно соединение для каждого контекста транзакции.


.3 The Core API
.;3 Базовый Программный Интерфейс
.^
Как ранее упоминалось, базовый программный интерфейс занимается
выполнением команд SQL.
Для этого сделано несколько функций, выполняющих запросы, равно как и
несколько вспомогательных функций для управления другими аспектами БД.
Существует два важных метода для выполнения команд SQL: подготовленные
запросы и wrapped запросы.
.; wrapped ---
Подготовленные запросы является

Prepared queries are the way in which \nm ultimately executes all commands,
both in the API and internally.

Подготовленные запросы представляют собой трех фазный процесс включающий подготовку,
выполнение и финализацию. В интерфейсе есть отдельные функции, связанные
с каждой фазой.
Функции, связанные с фазой выполнения, могут получить запись и информацию
о поле из отношения - результата.
.^
В дополнение к стандартному методу выполнения запроса, существует две
wrapper функции, которые все три фазы выполняют за единственный вызов.
Они предоставляют удобный путь для выполнения оператора SQL за раз.
Это только некоторые из многих различных вспомогательных функций в
программном интерфейсе.
В этой секции будут рассмотрены все методы выполнения запросов вместе
со связанными с ними вспомогательными функциями.
Но перед этим позвольте взглянуть на соединение с БД.


.4 Connecting to a DataBase
.;4 Cоединение с БД
.^
Соединение с БД влечет несколько больше, чем открытие файла.
Любая БД \nm хранится в одиночном файле файловой системы - одна БД
в одном файле.
Функция, которая используется для соединения или открытия БД в
програмном интерфейсе C называется $sqlite3_open()$ и, в основном,
является просто системным вызовом для открытия файла.
\nm, кроме того, может создавать БД в оперативной памяти компьютера (RAM).
.x +ram RAM
Для большинства языков, для этого нужно использовать либо строчку $:мемоry:$,
либо пустую строку в качестве названия для БД.
Такая БД будет доступна только для соединения, создавшего её (БД в RAM нельзя
совместно использовать с другим соединением).
Более того, такая БД будет существовать только во время жизни соединения.
Она удаляется из памяти после закрытия последнего.
.^
При выполнении соединения с БД на жестком диске, \nm открывает файл,
если он существует. При попытке открытия несуществующего файла \nm
не пытается немедленно создать новый файл в файловой системе.
Он будет создаваться только в случае, если в новую БД будет добавлено нечто
вроде таблицы, или представления или еще какого нибудь объекта БД.
Если просто открыть и закрыть новую БД, \nm не будет заморачиваться
с созданием файла для неё, все равно он останется пустым.
.^
Кроме того, существует важная причина для того, чтобы немедленно
не создавать новый файл.
Некоторые опции БД, такие как кодирование, размер страницы и
автоуплотнение можно менять только перед созданием БД.
По умолчанию, \nm использует страницы размером в 1024 байта.
При этом размер страницы можно задавать степенью двойки
в диапазоне от 512 до 32768 байт.
Их можно выбирать другими по причине производительности.
Например, совпадение размер страницы с размером страницы
операционной системы может сделать операции ввода - вывода более быстрыми.
Больший размер страницы ускоряет работу приложений, которые обрабатывают
большие объемы двоичных данных.
Для выбора желаемого размера страницы необходимо использовать
прагму $page\_size$.
.x $page\_size$
.^
Кодировка - это еще один неизменяемый параметр БД.
Можно выбрать кодировку для БД использую специальную прагму $encoding$,
выбирая из значений $UTF-8$, $UTF-16$, $UTF-16le$ (little endian) и
$UTF-16be$ (big endian).
.x little endian
.x big endian
.^
Наконец, прагма $auto\_vacuum$ позволит использовать автоупаковку БД.
По умолчанию, \nm не возвращает удаленные из БД страницы операционной системе.
После удаления записей из БД, размер файла БД не меняется.
Что бы освободить ненужные для БД страницы, необходимо
явно выполнить команду упаковки БД $vacuum$.
Возможность автоупаковки вынуждает \nm автоматически
ужимать файл БД, каждый раз когда из неё удаляются данные.
Эта возможность часто очень полезна для встроенных приложений,
когда ресурс памяти является критичным.
.^
После открытия любая БД, все равно на диске или в памяти,
будет доступна при помощи хендлера соединения $sqlite3$.
Такой хендлер представлят собой одиночное соединение с БД.
Объекты соединения из языков программирования абстрагируются от
этого хендлера и иногда реализуют методы, которые соответствуют
функциям программного интерфейса, получающие этот хендлер в качестве
аргумента.





.4 Execting Prepared Queries
.;4 Выполнение Подготовленных Запросов
.^
Как утверждалось выше, метод подготовленных запросов является
реальным процессом, при помощи которого \nm выполняет все
операторы SQL.
При этом выполнение команды SQL является трех шаговым процессом:
.(
.+
Подготовка: парсер, лексический анализатор и генератор кода
подготавливают оператор SQL, компилируя его в
.x ?vdbe байт код VDBE.
В программном интерфейсе языка C это выполняется при помощи
функции $sqlite3\_prepare\_v2()$, которая вызывается непосредственно
из компилятора. Компилятор создает хендлер $sqlite3\_stmt$
который содержит байт код и другие ресурсы,
необходимые для выполнения команды
и, если команда будет генерировать отношение - результат, последующего
прохода по результату выполнения команды;
.+
Выполнение: VDBE выполняет байт код.
Это выполнение является пошаговым процессом.
В программном интерфейсе C каждый шаг начинается при помощи функции
$sqlite3\_step()$, принуждающее VDBE к следующему шагу по байт коду.
Обычно первый вызов $sqlite3\_step()$ запрашивает блокировку некоторого типа.
Тип блокировки выбирается соответственно действиям выполняемым командой (чтение
или запись). Для оператора $select$ каждый обращение к функции
$sqlite3\_step()$
передвигает курсор хендлера к следующей записи отношения результата.
Для каждой записи в отношении функция будет возвращать $SQLITE\_ROW$
.x $SQLITE\_ROW$
до тех пор, пока не достигнет конца отношения, после чего
вернет $SQLITE\_DONE$.
.x $SQLITE\_DONE$
Для других операторов SQL ($insert$, $update$, $delete$ и так далее),
первый вызов функции $sqlite3\_step()$ принуждает
VDBE целиком выполнить команду;
.+
Финализация:
VDBE закрывает оператор и освобождает ресурсы.
В программном интерфейсе C, это происходит при помощи функции
$sqlite\_finalize()$, которая приводит к прекращению программы, освобождению
ресурсов и закрытию хендера команды.

.)
.^
Каждый шаг - подготовка, выполнение, финализация - соответствует
состоянию хендлера - подготовленный, активный или финализированный.
Состояние подготовленный означает, что все необходимые ресурсы уже выделены
и оператор готов к выполнению, однако выполнение не начато.
Не была затребована никакая блокировка, ни будет затребовано никакой блокировки
.; nor will a lock be acquired until to be executed
.;
.;
.;
до первого вызова функции $sqlite3\_step()$.
В этот момент оператор начинает выполняться и появляется блокировка
одного из типов.
Финализированный - означает, что оператор закрыт, все связанные с ним ресурсы были
освобождены. На
На рис.
.;+pic6-2

изоражены эти шаги и состояния.


.b
.;-
\begin {figure}[h]
\includegraphics[width=1.00\textwidth]{./m6_pics/test0.png}
\caption{Обратока оператора SQL}\label{pic6-2}
\end {figure}
.;-

.^
Следующий псевдокод иллюстрирует общий процесс выполнения запроса
в \nm:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p130_1.png}
.;-
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p131_1.png}
.;-
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p131_2.png}
.;-
Этот псевдокод является объектно - ориентированным аналогом
програмного интерфейса, подобного тому,
который можно найти в языках для написания скриптов.
Все методы соответствуют функциям программного интерфейса \nm.
например, $prepare()$ имитирует функцию $sqlite3\_prepare\_v2()$
и так далее.
Этот пример выполняет оператор $select$, проходя через
все возвращаемые строки, за которым выполняется оператор $insert$,
обработанный одиночным вызовом функции $step()$.
.= Временная память
.x временная память
.x Temporary storage
Временная память является важной частью обработки запроса.
\nm периодически нуждается в хранении промежуточных результатов, производимых
в процессе выполнения команды - например,
при необходимости сортировать вследствие использования фразы $order by$
или когда записи из одной таблицы соединяются с записями другой.
Тогда информация часто сохраняется во временной памяти.
Временная память находится либо в оперативной памяти компьютера или в файле.
Хотя \nm имеет умолчания подходящие для всех платформ,
сохраняется возможность контролировать как и где располагается временная память.
Прагма $temp\_storage$ позволяет указывать место для размещения временной памяти.
.x $temp\_storage$
При размещении временной памяти в файле, можно использовать прагму
$temp\_store\_directory$
.x $temp\_store\_directory$
чтобы указать каталог для хранения временных файлов.
.=


.4 Using Parameterized SQL
.;4 Использование параметризованного SQL
.^
Операторы SQL могут содержать параметры.
.x placeholder
.x спецификатор места вывода
Параметрами называются специальные обозначения (placeholder - спецификатор места вывода,
дословно - держатель места), задающие место в операторе SQL,
в которое в будущем будут подставляться значения (bound - связыванные).
Следующий операторы представляют примеры параметризованных запросов:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p131_3.png}
.;-
Здесь можно увидеть две формы связываемых параметров: связываемые по порядку и именованные.
Первая строка содержит параметры, связываемые по порядку, вторая использует именованные параметры.
.^
Параметры, связываемые по номеру, задаются символом вопроса в тексте оператора.
Первый вопрос отмечает позицию для первой величины, второй - для второй, и так далее.
Именованные параметры используют имена переменных, которые начинаются с символа двоеточие.
Когда $sqlite3\_prepare_v2()$ компилирует оператор с параметрами, она располагает
спецификаторы места вывода в хендлере подготовленного оператора.
Затем, перед выполнением, оператор ожидает получить значения для подставновки
в эти места. Если значения для связывания не предоставляется \nm будет использовать значение
$NULL$ во время выполнения оператора.
.^
Преимущество использования связывания параметров заключается в возможности
выполнять откомпилированный оператор несколько раз.
Необходимо просто связать новый набор значений со уже откомпилированным оператором
и выполнить его. Это полезнее, чем финализировать байт код и позволяет избавиться
от ненужной компиляции операторов SQL. Становится ненужной вся работа по лексическому и
синтаксическому разбору оператора SQL и повторной генерации байт кода.
Повторное связывание параметров выполняется при помощи функции $sqlite3_reset()$.
.^
Еще одно преимущество параметров заключается в ненужности экранирования символа кавычка.
К примеру, процесс связывания параметров самостоятельно сконвертирует строку вроде 'Kenny's Chicken'
в строку 'Kenny''s Chicken' - экранируя одиночную кавычку.
Это помогает избегать как синтаксических ошибок, так и возможных атак на БД при помощи SQL инъекции.
SQL инъекции будут рассмотрены ниже в секции 'Форматирование оператора SQL'.
Следующий псевдокод иллюстрирует основы использования связанных параметров:

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p132_1.png}
.;-

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p132_2.png}
.;-
Здесь, $reset()$ просто удаляет связанные ресурсы, но оставляет нетронутым байт код VDBE равно как и параметры.

.; непарные кавычки в пред файле портят раскраску текста в редакторе
.! Замечание
По видимому, отсутствует вызов функции $step()$
.!
Ранее подготовленный оператор не нуждается в дополнительном вызове функции $prepare()$.
Это позволяет улучшить производительность повторяемых запросов, так как полностью исключается
использование компиялтора.

.4 Executing Wrapped Queries
.;4 Выполнение Wrapped Запросов
wrapped
.^
Как уже упоминалось ранее, есть две очень полезные вспомогательные
функции, которые оборачивают процесс подготовки запроса,
позволяя выполнять оператор SQL за одиночный вызов функции.
Первая - $sqlite3\_exec()$ - типична для запросов, не возвращающих данные.
Вторая - $sqlite3\_get\_table()$ - типична для запросов, которые возвращают их.
Во многих языках расширениях можно обранужить аналоги для обеих.
Часто на первую ссылаются просто как на $exec()$, а на вторую - $get\_table() $.
.^
Функция
$exec()$ является быстрым и удобным способом выполнять операторы $insert$, $update$, $delete$
или операторы языка определения данных (DLL) для создания и удаления объектов БД.
Он а работает непосредственно на соединении, получая хендлер $sqlite3$ к открытой БД
и строчку, содержащую один или более операторов SQL. Это правда:
функция
$exec()$ способна обработать строку с несколькими операторами SQL, которые разделяются символом
точка с запятой, и выполнить их все вместе.
.^
Для этого $exec()$ выполняет синтаксический анализ строки, выделяет отдельные операторы и
обрабатывает их один за другим. Она захватывает память для хендлеров операторов, подготавливает,
выполняет и финализирует каждый из них.
Если она получила несколько SQL операторов и один из них сбойнул,
функция
$exec()$ прекращает работу и возвращает соответствующий код ошибки. Иначе
она возвращает код успешного завершения.
Следующий псевдокод концептуально иллюстрирует применение функции
$exec()$ в языках расширениях.
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p133_1.png}
.;-
Хотя можно использовать
$exec()$ для обработки записей, возвращаемых из оператора $select$,
но это подразумевает изощренные методы, полностью поддерживаемые
только в программном интерфейсе C.
.^

Название второй функции, $sqlite3\_get\_table()$, может вводить в заблуждение,
ибо она не ограничивается запросами к одиночной таблице.
Скорее, её имя подразумевает отношение результат выполнения любого оператора $select$.
Естественно, ей можно стаким же успехом обрабатывать соединения таблиц.
Во многом, $get\_table()$ выполняется так же как и $exec()$,
но возвращает результат отношение. Это отношение может быть
представлено различными способами, в зависимости от языка расширения.
Следующий псевдокод иллюстрирует типичное использование функции:

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p133_2.png}
.;-
Важной чертой $get\_table()$ является то, что она предоставляет одношаговый метод для
запроса и получения отношения результата.
Это означает, что чем больше отношение результат, тем больше памяти использует функция.
Не должно быть сюрпризом, что не следуют её использовать для получения больших наборов данных.
С другой стороны, помните, что метод подготавливаемых запросов
использует память только для одной записи (в реальности для одной страницы,
на которой расположена запись), что лучше подходит для прохода через
большие отношения результаты.
.^
Отметим, что хотя эти функции предоставляют некоторое удобство,
они прячут доступ к хенлеру оператора, что приводит к ослаблению
контроля. Например, с ними нельзя использовать параметризованные операторы SQL.
Кроме того, программный интрефейс предоставляет функции, которые пользуются
хендлерами оператора. Эти функции предоставляют информацию про поля в отношении результате
(как про данные, так и про метаданные). Но эта информация не доступна при использовании
wrapped запросов.

.4 Handling Errors
.;4 Обработка Ошибок
.^
Приведенные примеры были слишком упрощены для иллюстрации основ обработки запросов.
В реальности, необходимо уделять внимание обработке ошибок.
Почти каждая из уже обсужденных функций может вызвать к какой нибудь ошибке.
Коды ошибок, к обработке которых нужно быть готовым включают
$SQLITE\_ERROR$ и $SQLITE\_BUSY$.
Последний из которых, ссылает на условие занятости, возникающее в случае
невозможности поставить блокировку.
Условие занятости обсуждается в секции 'Транзакции',
в то время как ошибки описываются в деталях в главе
.;+m1-6
.
.^
Применительно к большинству ошибок,
программный интерфейс при помощи $sqlite3\_errcode()$
предоставляет код возврата
функции, вызванной перед $sqlite3\_errcode()$.
При помощи
$sqlite3\_errmsg()$
можно получить более детальное описание этой ошибки.
Многие языки расширения поддерживают эти функции тем или иным способом.
.^
Если озаботится ошибками, то каждый вызов функции в
предыдущих примерах должен проверять код возврата приблизительно
в таков виде:


.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p134_1.png}
.;-
.^
Вообще говоря, обработка ошибок не слишком сложна.
Способ обработки зависит от того, что точно требуется сделать.
Наиболее простой из них такой же как и в любом другом
программном интерфейсе - аккуратно читать документацию про используемую
функцию и возвращаемые ей коды ошибок.


.4 Formatting SQL Statements
.;4 Форматирование SQL Операторов
Еще одна удобная и приятнай функция, которую могут предлагать некоторые языки расширения,
называется
$sqlite3\_mprintf()$. Она является вариантом стандартной функцией C - $sprintf()$.
Её спецификаторы места вывода, специфические для SQL, могут быть весьма полезны.
Они обозначаются как \%q и \%Q и используются для значений, специфических для SQL.
\%q работает похоже на \%s, и используется для вывода строк, заканчивающихся нулем.
Но кроме того, спецификатор удваивает каждую одиночную кавычку, облегчая жизнь программиста
и предоставляя защиту против SQL инъекции. Подробности см. в секции 'Атака при помощи SQL инъекции'.
Далее, смотри пример:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p134_2.png}
.;-
Величина переменной $after$ равняется 'Hey, at least he''s no pig-man'.
Одиночная кавычка в he's удваивается, делая правильной строчную константу в операторе SQL.

.; непарные кавычки в пред файле портят раскраску текста в редакторе
Спецификатор \%Q все делает точно так как \%q,
но дополнительно заключает результирующую строку в одинарные кавычки.
Но если через %Q выводится нулевой указатель (в смысле C),
то результирующая строка будет $NULL$ без одинарных кавычек.
Для дальнейшей информации смотри документацию по $sqlite3\_mprintf()$
в руководстве по программному интерфейсу C.
.= Атака при помощи SQL инъекции
Приложение становится уязвимым для
атака при помощи SQL инъекции,
если будет полагаеться на вводимые данные для конструирования
операторов SQL.
Если не внимательно относится к фильтрованию пользовательского ввода, то
для недобросовестного пользователя
появляется возможность ввести дополнительный оператор SQL.
К примеру, приложение использует пользовательский ввод, что бы
подставить его значение в следующий оператор SQL:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p134_3.png}
.;-
Тут спецификатор места вывода \%s заменяется на все, что введет пользователь приложения.
Если пользователь имеет информацию о БД приложения, он может
ввести строку, которая драматически измент рассматриваемый оператор SQL.
Таким примером является следующая строка:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p134_4.png}
.;-
После выполнения подстановки в рассматриваемый оператор SQL, он преватится
в два:

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p135_1.png}
.;-

Первый оператор не вернет ничего, а второй - вернет в приложение имена объектов
из БД.
Естественно, странности поведения SQL требуют знаний атакуемого приложения,
но это не является невозможным. Даже коммерческие веб приложения хранят
операторы SQL в своих скриптах языка JavaScript, а они
имеют достаточно подсказок о используемой БД.
В рассмотренном примере, злоумышленник может вставить оператор $drop~ table$
для каждой таблицы, найденной в $sqlite3\_master$, что приведет к необходимости
продираться через бекапы БД.
.=

.3 Operational Control
.;3 Оперативное Управление
.^
Програмный интерфейс предоставляет набор возможностей для
наблюдения, управления и ограничения событий, происходящего в БД.
\nm реализует эти возможности либо в форме фильтров, либо в форма
функций обратного вызова, которые необходимо регистрировать для заданных событий.
Есть три hook-функции: $sqlite3\_hook()$ - для наблюдения за коммитами
на соединении,
$sqlite3\_rollback\_hook()$ - для наблюдения за откатами,
$sqlite3\_update\_hook()$ - для наблюдения за изменениями в записях,
которые вызываются операторами $insert$, $update$ и $delete$.
.^
Эти функции вызываются во время выполнения приложения - во время выполнения оператора SQL.
Каждая hook - функция позволяет регистрировать функцию обратного вызова на
.;----юж
основе коннекшен бай коннекшин
и так же позволяет передавать данные, специфические для приложения, в функции
обратного вызова..
Функции оперативного управления вообще говоря, должно
использовать как приводится ниже:

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p135_2.png}
.;-
.! Замечание
.^
По видимому, в примере есть описка с названием функции:
$commit\_hook(cnx)$ и $rollback\_hook(cnx)$ -
скорее всего, должно быть одно и тоже имя.
.!


Значение, которое возвращает hook-функция, имеет возможность повлиять на поведение
SQLite некоторым способом, в зависимости от вида функции.
В этом примере выполнится откат, так как hook-функция возвращает не нулевое значение.
.^
Дополнительно, программный интерфейс предлагает очень мощную
hook - функцию времени компиляции с названием
$sqlite3\_set\_autorizer()$.
Она предоставляет очень тонкий контроль над практически всем,
что может в БД, так же как и возможность ограничивать возможности доступ
и редактирования БД, таблиц, и полей.
Детально она будет описываться в главе
.;+m1-6
.

.3 Using Threads
.;3 Использование Ниток (Потоков)
.^
\nm предоставляет несколько
функций
для использования во многопоточных среде.
Начиная с версии 3.3.1 \nm
ввел уникальный режим управления с названием режим разделяемого кэша
(shared cache mode),
.x режим разделяемого кэша
.x shared cache mode
который спроектирован для встроенный многопоточных серверов.
Он предоставляет возможность для одиночного потока (нитки)
иметь несколько соединений так, что они разделяют общий кэш страниц,
снижая таким образом общее использование памяти сервером.
Кроме того, добавляется еще одна модель конкуренции.
Добавленные с этими возможностями функции позволяют управлять
памятью и тонкой настройкой сервера.

Еще раз оперативное управление будет обсуждаться позже,
в секции 'Режим разделяемого кэша' и
в главе
.;+m1-6
.

.2 +m1-5-2 The Extention API
.;2 +m1-5-2 Расширенный Программный Интерфейс
.^
Расширенный программный интерфейс в программном интерфейсе \nm С
предлагает поддержку определяемых пользователем функций, групповых функций и
сортирующих последовательностей.
Функция, определяемая пользователем, разрабатывается
на языке C или любом другом языке и может вызываться из
запросов языка SQL в \nm.
Так же будет называться пользовательски расширением.
.x пользовательское расширение
.^
User-defined extensions must be registered on a connection-by-connection basis as they are stored
in program memory
.;----
То есть, они не сохраняются в БД, подобно хранимым процедурам
в других РСУБД.
Они храняться в приложении. Когда приложение
(или скрипт) начинает работать, оно обязано
зарегистрировать пользовательское расширение для каждого
соединения, которое должно использовать расширение.




.;3 Creating User-Defined Functions
.3 Создание Функций, Определяемых Пользователем
.^
Разработка определяемой пользователем функции является двухшаговым процессом.
Значала пишется обработчик, который
делает нечто, что предполагается использовать из языка SQL.
Затем обработчик регистрируется с некоторым именем для языка SQL,
списком формальных параметров и указателем на обработчик.
.^
Предположим, требуется создать специальную функцию для SQL с названием
$hello\_newman()$, которая возвращает строку 'Hello Yerry'.
Сначала требуется написать функция на языке C, вроде следующей:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p136_1.png}
.;-
.b
Далее, требуется её зарегистрировать при помощи $sqlite3\_create\_fuction()$
(или, в случае другого языка расширения, при помощи её эквивалента):
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p136_2.png}
.;-
.b
Первый фактический параметр $db$ - это соединение с БД.
Второй - имя функции, как предполагается её называть в языке SQL,
третий означает, что у функции нет формальных параметров.
Значение -1 означает, что она может обрабатывать любое число формальных параметров.
Последний параметр - это указатель на выше приведенную функцию C $hello\_newman()$.
Она и будет вызываться, в случае использование $hello\_newman()$ на языке SQL.
.^
\nm теперь знает, что встретив в SQL запросе функцию $hello\_newman()$,
он должен вызвать сишную функцию $hello\_newman()$ для получения результата.
То есть, следующий запрос
.n
select hello_newman()
.f
в приложении, выполнившем описанную регистрацию, вернет одну запись с одним полем,
которое содержит текст 'Hello Jerry'.
Как упоминалось в главе
.;+m2-4
определяемые пользователем функции являются специальным способом для создания ограничений целостности,
используемых во фразе $check$.



.;3 Creating User-Defined Agregates
.3 Создание Групповых Функций, Определяемых Пользователем
.^
.x agregates
.x групповая функция

Групповые функции (agregates) это функции, которые
применяются ко всем записям в отношении результате
и вычисляют из нех некоторое значение, общее для них.
Примерами стандартных групповых функций из языка SQL являются функции
$sum()$,
$count()$ и
$avr()$.
.^
В \nm
при помощи процесса из трех шагов можно создать дополнительную групповую функцию.
Таким образом необходимо:
.(
.+
зарегистрировать групповую функцию;
.+
разработать функцию, которая вызывается для каждой записи в отношении результате;
.+
разработать финальную функцию, которая вызывается после обработки всех записей.
Она позволяет вычислять окончательное значение и выполняет очистку памяти.
.)
.^
Проиллюстрируем сказанное примером создания групповой функции
$pysum$ для вычисления суммы для одного из языков расширений, а именно - Python:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p137_1.png}
.;-
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p137_2.png}
.;-


Вызов функции \nm
$createaggreatefuction()$ регистрирует групповую функцию, получая
функции Python-а
$step()$ и
$finalize()$.
\nm использует
переменную $contex$, для хранения промежуточных значений
между вызовами
$step()$.
После обработки последней записи вызывается $finalize()$,
в данном примере она просто выводит посчитанную сумму.
Также об очистке $contex$
\nm позаботится самостоятельно.

.;-----4444
.;3 Creating User-Defined Collations
.3 Создание Определяемых Пользователем Сортирующих Последовательностей
.^
.x collation
.x сортирующая последовательность
Сортирующие последовательности используются для
определения порядка сравнения строк.
Таким образом, сортирующие последовательности,
определяемые пользователем, являются способом для
дополнительных способов сортировки и сравнения строк.
Для этого в программном интерфейсе существует функция
$sqlite3\_create\_collation()$.
По умолчанию \nm предоставляет три сортирующих последовательности:
BINARY, NOCASE и RTRIM.

BINARY сравнивает строки при помощи функции $memcmp()$
из библиотеки C (чувствительной к регистру во всех случаях).
NOCASE - просто её противоположность, она нечуствительна к регистру.
RTRIM сравнивает строки так же, как и BINARY, за исключением
игнорирования завершающих пробелов.
.^
Сортирующие последовательности,
определяемые пользователем, особенно полезны для настроек локальных языков
(в смысле русский или арабский, а не Pascal), которые
не слишком хорошо сравниваются при помощи последовательности BINARY,
или тех, которые нуждаются в поддержке для кодировки UTF-16.
Кроме того, их полезно применять для сортировок дат, формат которых,
не предназначен для хронологического или лексикографического упорядочения.
В главе
.;+m1-7
приводится
иллюстрация применения в \nm
сортирующей последовательности дат, используемой в
СУБД Oracle.


.2 +m1-5-3 Transactions
.^
К этому моменту общее представление о программном интерфейсе уже должно быть
сформировано.
Были проссмотрены способы выполнения операторов SQL при помощи
полезных вспомогательных функций.
Но выполнение операторов SQL, однако,
подразумевает некоторые знания за пределами функций.
С обработкой запросов тесно переплетены
транзакции и блокировки.
Запросы всегда выполняются внутри транзакций,
транзакций не бывает без блокировок,
а, без правильного использования,
блокировки вызывают проблемы.
Используя SQL и возможности записывания операторов необходимо
управлять типом и длительностью блокировок.
.^
В главе
.;+m2-4
обсуждалось возникновение
клинча (deadlock)
.x клинча
.x deadlock
.; ----------- клинч
когда два соединения управляют своими транзакциями исключительно при помощи
операторов SQL.
Программист должен уметь управляться с кодом, в котором есть несколько
соединений в различных состояниях различных хендлеров команд на
различных таблицах в один и тот же момент времени.
Все, что требуется, чтобы приложение висело на блокировке EXCLUSIVE,
не давая другим соединениям ничего делать,
это хендлер одиночного оператора,
.^
Поэтому критически важно хорошо вкурить как работают
и транзакции, и блокировки и как они относятся к функциям
программного интерфейса при выполнении запросов.
Было бы идеально, при взгляде на несколько написанных строчек кода,
объяснить каком состоянии находится транзакция или хотя бы предположить
место потенциальных трудностей.
В этой секции исследуется механизм выполнения транзакций и блокировок, а
в следующей секции просмотрим как они работают в реальных программах.

.;3 Transaction Life Cycles
.3 Жизненный Цикл Транзакции
.^
Касательно транзакций и блокировок необходимо знать пару фактов.
Сначала требуется знать какие объекты выполняются в транзакции.
Затем возникает вопрос длительности транзакций - когда транзакция
начинается, как долго она тянется и когда начинает влиять на другие
соединения?
Первый вопрос касается исключтельно программного интрефейса.
Второй - касается SQL вообще и его конкретной реализации в \nm.
.^
Как известно, при помощи единственного соединения можно создать
несколько хендлеров команд.
И, как показано на рис.
.;+pic6-2
, каждое соединение с БД имеет в точности одно B-дерево и один, ассоциированный с ним
менеджер страниц.
Менеджер страниц играет большую роль, чем соединение в
этой теме, потому что он управляет транзакциями, блокировками, кэшем памяти и
восстановлением после краха - это все будет объясняться в нескольких
следующих секциях.
Для упрощения можно говорить, что соединение занимается этим всем,
но на деле, этим занимается менеджер страниц из соединения.
Важная деталь, которую надо помнить про запись в БД при одном соединении это то,
что в каждый момент времени есть только одна транзакция.
То есть, в каждой транзакции соединения выполняются все объекты операторов,
которые были построены для этого соединения. Это ответ на первый вопрос.
.^
Что до второго вопроса, то длительность транзакции может быть либо такой короткой,
как один оператор или такой длинной как надо, до тех пор, пока не будет сказано: 'Стоп'.
По умолчанию, соединение работает в режиме автокоммита, это оазначает, что
каждый оператор выполнялся в отдельной транзакции.
И напротив, после встреченного ключевого слова $begin$, транзакция тянется
до тех пор, пока не встретит слова
$commit$ или
$rollback$, или до тех пор пока один из операторов SQL не вызовет нарушение целостности БД,
что завершается откатом.
Далее надо рассмотреть вопрос как транзакции связаны с блокировками.