Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / SQLite Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4      [все]
 книжки по Sqlite на русском языке..  [new]
AlexSem
Member

Откуда:
Сообщений: 24
Всем доброго времени суток,
тут меня попросили книжку скачать на русском, но я ничего не нашёл кроме
http://sqlite.org/books.html
а там всё на английском, желательно в pdf или html формате,
поделитесь кому не жаль,
Спасибо.
28 мар 14, 19:32    [15803036]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
http://agp1.hx0.ru/.SQLite.Allow.pdf

перевод в процессе.
за указанные ошибки моя благодарность не будет знать границ в разумных пределах
31 мар 14, 12:46    [15810597]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10436
tchingiz
http://agp1.hx0.ru/.SQLite.Allow.pdf

перевод в процессе.
за указанные ошибки моя благодарность не будет знать границ в разумных пределах



куда указывать ошибки?
1 апр 14, 14:53    [15816252]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
хоть сюда или в программирование пошли
1 апр 14, 16:17    [15817047]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10436
tchingiz
хоть сюда или в программирование пошли


4.4.11

...

кроме того, отношения в составных запросах обрабатываются слева на пра-
во.
направо.

Операция union два различных отношения A и B соединяет в одно, ко-
торое содержит записи из обеих обоих
1 апр 14, 18:35    [15817948]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
фиксед.
версия 0.43
1 апр 14, 19:42    [15818152]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
AlexSem
Member

Откуда:
Сообщений: 24
tchingiz,

2.3 Особенности И Философия

может букву "И" нужно писать не заглавным ?
2 апр 14, 13:37    [15821168]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
fd00ch
Member

Откуда: Нижний Новгород
Сообщений: 5913
сдается мне, автор ждал репортов не о таких ошибках
2 апр 14, 14:37    [15821639]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10436
fd00ch
сдается мне, автор ждал репортов не о таких ошибках


и таких наверное тоже.. тем более он переводит книгу, а не пишет ;-)
2 апр 14, 15:53    [15822237]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
AlexSem,
фиксед
12 апр 14, 00:13    [15871080]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
fd00ch
сдается мне, автор ждал репортов не о таких ошибках

о любых
12 апр 14, 00:13    [15871082]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
закончен черновик 2 3 и 4 глав

C H A P T E R 2 Getting Started

C H A P T E R 3 SQL for SQLite

C H A P T E R 4 Advanced SQL for SQLite
12 авг 14, 13:48    [16430959]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
MaratIsk
Member

Откуда: Astana, Kazakhstan
Сообщений: 2475
tchingiz,

Впервые выпущенНа в 2000 году - стр. 3 Введение
компактрая - стр. 3 Введение
эпроизводительная ??? стр. 3 Введение
что её (база данных ?) существует не как процесс стр. 3, параграф 2.1
как тригера (как триггеры) стр. 4, параграф 2.3

для начала :)
13 авг 14, 09:21    [16434714]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10436
MaratIsk
tchingiz,

Впервые выпущенНа в 2000 году - стр. 3 Введение
компактрая - стр. 3 Введение
эпроизводительная ??? стр. 3 Введение
что её (база данных ?) существует не как процесс стр. 3, параграф 2.1
как тригера (как триггеры) стр. 4, параграф 2.3

для начала :)


"компактрая" - компактная версия рая
"эпроизводительная" - электронная производительная база данных
"тригера" - тракторА, векторА

13 авг 14, 18:12    [16438163]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
MaratIsk
Member

Откуда: Astana, Kazakhstan
Сообщений: 2475
Winnipuh
MaratIsk
tchingiz,

Впервые выпущенНа в 2000 году - стр. 3 Введение
компактрая - стр. 3 Введение
эпроизводительная ??? стр. 3 Введение
что её (база данных ?) существует не как процесс стр. 3, параграф 2.1
как тригера (как триггеры) стр. 4, параграф 2.3

для начала :)


"компактрая" - компактная версия рая
"эпроизводительная" - электронная производительная база данных
"тригера" - тракторА, векторА



ааа!!!
вон оно как!
то-то мне русский не родной
13 авг 14, 21:14    [16438661]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
0.64 фиксед
триггера мне больше нравятся
14 авг 14, 15:54    [16442118]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
MaratIsk
Member

Откуда: Astana, Kazakhstan
Сообщений: 2475
tchingiz
0.64 фиксед
триггера мне больше нравятся


тебе может нравиться - доет карова малако
но, если хочешь, чтоб тебя понимали многие - лучше придерживаться правил языка
14 авг 14, 16:33    [16442389]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
http://otvet.mail.ru/question/67609341
за трактора больше ответов
многие поймут
15 авг 14, 10:13    [16444571]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10436
tchingiz
http://otvet.mail.ru/question/67609341
за трактора больше ответов
многие поймут


поймут и простят (ц)
20 авг 14, 11:38    [16467003]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
Почитал, обрывается на самом интересном месте, главу 6 почитать бы, я так понимаю там описаны хитрости для эффективного использования.
Хорошая книга для освоения Sqlite с нуля.
+ ошибки и опечатки
стр. 47 таб. 4.1 несколько раз повторяется "логическое и", "логическое или" с разным приоритетом, наверно & и AND разное обозначают
стр.78 п.5.2.1.2 "_rowia_" наверно подразумевалось "_rowid_"
стр. 84 п.5.2.2.4 обычно принято называть таблицы "дочерними", а не "детскими"
стр. 88 как-то путано приоритеты класов памяти описаны, обычно наивысший это первый, а тут последний.
стр.89 п.5.2.4 обычно "view" переводят как "представление" и стр.90
стр.94 опечатка "не нее" вместо "на нее"
стр.95 п.5.2.6.3 "Обновляемые обзоры" => "представления", возможно не "обновляемые", а "изменяемые", но не настаиваю.
стр.96 п. 5.3.1 опечатка "degin" вместо "begin", "будте" вместо "будет"
стр.97 п. 5.3.1 опечатка "с произвольны" вместо "с произвольным"
стр.97 п. 5.3.2 опечатка "возожность" вместо "возможность"
9 июл 18, 15:25    [21556619]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
сенкс.
читай по английски?
эм, в 6 главе не тонкости, а сишный интерфейс, видимо.
ну, сяду фиксить твои замечания,
может займусь шестой главой.
Гдето первый сишный пример я уже строил.
9 июл 18, 19:19    [21557504]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T,

ооо, так ты теперь туда

https://www.sql.ru/forum/1297587/knigi-sql

сообщи, что немного подкорректировал свое мнение
9 июл 18, 19:30    [21557511]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
ShSerge
Member

Откуда: ʚонɔ dиw
Сообщений: 24853
SQLite - классная штука. Только что закончил этап проекта. SQLite+PHP+Javascript. Использую jqGrid. Всем рекомендую.
9 июл 18, 20:40    [21557653]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
tchingiz
сенкс.
читай по английски?
эм, в 6 главе не тонкости, а сишный интерфейс, видимо.

Про С вроде как 7-я "The Core C API", 6-я "SQLite Design and Conceptions".
Качнул на английском,
Поищу на английском, правда я плохо на нем читаю.

tchingiz
сообщи, что немного подкорректировал свое мнение

Мнение не поменялось. Данная книга подходит тем кто уже работал с какой-нибудь СУБД.
В том топике вопрос про SQL. ИМХО изучение SQL неразрывно связано со знанием теории РСУБД, которая тут вообще не упоминается.
Иначе потом появляются топики: "у меня вот такая черезжопная структура БД помогите написать select", а select не написать, т.к. изначально проигнорированы все правила проектирования БД.
10 июл 18, 09:07    [21558282]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T
Мнение не поменялось.

ну, тогда не сообщай.
У них было введение - не главаа, и глава 1 введение в SQLite

К сообщению приложен файл. Размер - 20Kb
10 июл 18, 14:53    [21559608]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
о.
на https://www.apress.com/gp/book/9781590596739
уже лежит другая версия, ее редактировал разработчик
и появилась глава про теорию (как ты хотел)))
Полностью скачать, по видимому, нельзя.
Я второе издание качал оттуда.
10 июл 18, 14:59    [21559630]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
tchingiz
У них было введение - не главаа, и глава 1 введение в SQLite

Теперь понятно почему нумерация съехала в переводе. Я в русском смотрел.

Картинка с другого сайта.
10 июл 18, 15:04    [21559644]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
автор
стр. 47 таб. 4.1 несколько раз повторяется "логическое и", "логическое или" с разным приоритетом, наверно & и AND разное обозначают



select 7 | 0;

возвращает 7 (битовое или)

select 7 or 0;
возвращает 1;


на сайте | и & относятся к математическим операциям.
автор
Operators

All mathematical operators (+, -, *, /, %, <<, >>, &, and |) cast both operands to the NUMERIC storage class prior to being carried out.
16 июл 18, 15:57    [21575175]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
Если так, то я бы назвал & и | побитовыми И и ИЛИ.
16 июл 18, 16:08    [21575225]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T,

)), ну я же не свою книгу пишу
16 июл 18, 16:59    [21575440]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
я все вроде пофиксил кроме
р. 88 как-то путано приоритеты класов памяти описаны, обычно наивысший это первый, а тут последний
ничего путанного не нашел.
Это не приоритеты классов памяти, это задается линейный порядок на множествах.
Обычно с маленьких значений начинают и переходят к большим.
16 июл 18, 17:02    [21575452]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Если ты будешь читать 5-6 главу про тонкости и запишешь результат чтения,
то, наверно, можно будет её добавить.
Можно мелкими порциями
16 июл 18, 17:04    [21575457]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
tchingiz
Dima T,

)), ну я же не свою книгу пишу

Оригинал посмотрел - это косяк автора, обычно делают добавку (прим. переводчика)

В остальном оно так во многих книгах называется, поэтому считаю что надо поправить автора.
16 июл 18, 20:38    [21576086]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T,
замечание добавил еще днем
16 июл 18, 20:57    [21576114]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
+

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

16 июл 18, 22:04    [21576187]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
tchingiz
Если ты будешь читать 5-6 главу про тонкости и запишешь результат чтения,
то, наверно, можно будет её добавить.
Можно мелкими порциями

Почитал 5-ю (Design and Conceptions). Не без гуглоперевода.
Ничего особенного не вычитал, большая часть повтор упомянутого ранее. Из интересного - конец (раздел Code), где разбираются различные ситуации параллельного доступа и описано как при этом работают блокировки.

6-ю (The Core C API) полистаю, но мне в C# надо, поэтому нет смысла глубоко вникать в тонкости C API.
17 июл 18, 12:49    [21577397]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
с api не читай, раз не надо.
5-6 главу я имел ввиду ту, которой мы давали разный номер.
17 июл 18, 21:23    [21579096]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T,
черт дернул по пьяни сделать всю скучную работу в главе про дизайн и концепции,
ты будешь в переводе участвовать?
21 июл 18, 22:10    [21591490]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
tchingiz
ты будешь в переводе участвовать?

Я тот еще переводчик, но могу почитать готовое, ошибки поискать.
22 июл 18, 18:57    [21592358]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
Еще немного опечаток, красным то что надо править:
п. 2.2.1 ... из м C API ....
п. 3.4.1 ... SQLite создаcт БД ...
п. 3.4.1 ... предшевствующие ...
п. 3.4.1 ... добавим индекс и обзор представление к БД.
ИМХО там много где еще обзоры упоминаются, поэтому больше про них не пишу, лучше поиском пройтись.
п. 3.4.2 ... Что бы (слитно пишется)
п. 3.4.5 ... как поля, разделенные умолчательным сепаратором с разделителем по-умолчанию
п. 3.4.5 ... таблицы в SCV CSV формате
п. 3.4.6 ... Экспортирование
п. 4.3.1 ... Таким образом,
п. 4.3.1 ... Вообще говоря, этот термин использоваться Этот термин используется, что бы (слитно) отличать
п. 4.4.8 ... Без операцияи соединения невозможно представить работу с несколькими
таблицами (или отношениями),
п. 4.4.8 ... В свою очередь, поле
п. 4.4.12 ... Запрос выполняит подзапросы
п. 4.4.12 ... только одной веткаи when.
п. 4.4.13 ... некоторые могут не соглашаться согласиться с этим утверждением.
п. 4.4.13 ... может вызвать удивлениюе
п. 4.4.13 ... любое значение отличное от нуля являет-ся правдой
22 июл 18, 20:26    [21592465]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
ок.
в тексте ниже
- \nm это макрос для строчки SQLite
- точка в первом символе строки начинает команду
.1 начинает глава - раздел уровня один
.2 начинает раздел уровня два
.3 начинает раздел уровня три
и так далее.

.; - коментарий

+

.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 равно как и параметры.



22 июл 18, 20:55    [21592492]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
в ихнем апи
соединения и операторы,
а в нашем .Нет провайдере - соединения и команды.
Я начал писать операторы для апи, операторы скл для скл,
а потом гдето рука дрогнула изза провайдера и перешел на команды
:((
22 июл 18, 21:19    [21592503]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
Почитал.

pager управляет физическим размещением данных в БД, кэшированием страниц в память, запись изменений на диск и т.д. Я бы назвал его менеджер страниц.
B-tree как понимаю какая-то внутренняя структура хранения метаданных - какая страница что содержит и т.д. Как перевести - не знаю.

wrapped запросы - это надстройка над основным API, для облегчения написания кода.

Опечатки:
Структура соединение предоставляет
... любоую операцию над БД
23 июл 18, 08:34    [21592981]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T
Почитал.

pager управляет физическим размещением данных в БД, кэшированием страниц в память, запись изменений на диск и т.д. Я бы назвал его менеджер страниц.

да, White Owl тоже так сказал.
Ты в зпт ходишь?
+

.; непарные кавычки в пред файле портят раскраску текста в редакторе
.! Замечание
По видимому, отсутствует вызов функции $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.

23 июл 18, 11:43    [21593575]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
по поводу враппед -- склоняюсь к "немедленным" запросам.
23 июл 18, 11:45    [21593584]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
В зпт не хожу, самозабанился там.

"Немедленные" запросы - в принципе подходит по смыслу.

Опечатки:
компиялтора
обранужить
DLL вместо DDL
с|таким же успехом
может вызвать к какой нибудь ошибке какую-нибудь ошибку
вариантом стандартной функцией и
23 июл 18, 12:53    [21593871]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T


"Немедленные" запросы - в принципе подходит по смыслу.

ок.

Dima T
Опечатки:
компиялтора
обранужить
DLL вместо DDL
с|таким же успехом
может вызвать к какой нибудь ошибке какую-нибудь ошибку
вариантом стандартной функцией и

фиксед

поменял на
аналогом стандартной функции
--
23 июл 18, 13:03    [21593954]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
+
.; непарные кавычки в пред файле портят раскраску текста в редакторе
Спецификатор \%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 позаботится самостоятельно.


24 июл 18, 17:33    [21599037]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
Опечатки:
драматически изменит
либо в формае функций
Использование Нитокей (Потоков)
и далее по тексту все "нитки" на "нити",
который спроектирован для встроенныйх многопоточных серверов.

Это надо переформулировать "Функции оперативного управления вообще говоря, должно использовать как приводится ниже:"
Например в "Ниже приведен пример использования функции оперативного управления:"
25 июл 18, 08:12    [21600094]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
фиксед.
1
шото у меня не формулируются внизу 140 страницы объяснения для картинки про блокировки.


2

+
.;-----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 не вызовет нарушение целостности БД,
что завершается откатом.
Далее надо рассмотреть вопрос как транзакции связаны с блокировками.


3
на тебя в переводе ссылаться ником на форуме или через фио?
25 июл 18, 13:34    [21601090]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
1. Картинка как называется? Если SQLite lock transitions, то у меня она внизу стр. 187.
ИМХО автор нафантазировал немного про PENDING. В цепочке UNLOCKED->PENDING->SHARED лишний PENDING, т.к. зачем ужесточать блокировку, если потом опять понизить?
В документации про нее просто написано:
Блокировка PENDING означает, что процесс, содержащий блокировку, хочет как можно скорее записать в базу данных и просто ждет, пока все текущие блокировки SHARED будут освобождены, чтобы он мог получить блокировку EXCLUSIVE. Никакие новые блокировки SHARED не допускаются к базе данных, если активна блокировка PENDING, хотя существующие блокировки SHARED продолжают работать.

В русском варианте уже есть п. 5.3.3. про блокировки, перечитай, может поможет.

2. Замечаний нет.

3. На меня ссылаться никак не надо, анонимность важнее.
25 июл 18, 14:30    [21601245]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
Там же в документации нет ничего про UNLOCKED->PENDING->SHARED
5.0 Запись в файл базы данных
Чтобы записать в базу данных, процесс должен сначала получить блокировку SHARED, как описано выше (возможно, откат неполных изменений, если есть горячий журнал). После того, как получена SHARED, необходимо получить блокировку RESERVED. Блокировка RESERVED сигнализирует, что процесс намеревается записать в базу данных в какой-то момент в будущем. Только один процесс за один раз может удерживать блокировку RESERVED. Но другие процессы могут продолжать читать базу данных, пока удерживается блокировка RESERVED.

Если процесс, который хочет писать, не может получить блокировку RESERVED, это должно означать, что другой процесс уже имеет блокировку RESERVED. В этом случае попытка записи не удалась и возвращает SQLITE_BUSY.
...
25 июл 18, 14:48    [21601337]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908


К сообщению приложен файл. Размер - 26Kb
26 июл 18, 00:06    [21602954]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908


К сообщению приложен файл. Размер - 41Kb
26 июл 18, 00:06    [21602955]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T
1. Картинка как называется? Если SQLite lock transitions, то у меня она внизу стр. 187.

у тебя таки третье издание?
26 июл 18, 00:16    [21602964]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
tchingiz
Dima T
1. Картинка как называется? Если SQLite lock transitions, то у меня она внизу стр. 187.

у тебя таки третье издание?

Не знаю, там не написано. Но картинка та самая, которую ты показал.
26 июл 18, 07:31    [21603083]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
+

.;-----555

.;3 Lock States
.3 Состояния Блокировок
.^
В большинестве случаев продолжительность блокировки приближается к продолжительности
транзакции.
Хотя они начинаются раздельно, они всегда заканчиваются вместе.
При завершении транзакции, освобождается связанная с ней блокировка.
Другими словами,
блокировка не заканчивается до тех пор, пока не завершается её транзакция или
не сбойнет приложение.
И, после краха приложения или системы, транзакция не завершается,
в этом случае в БД остается неявная блокировка с которой начнет работу следующее соединение.
Эту тема уточняется позднее в секции 'Блокировки и Восстановление После Краха'.
.^
В \nm существует пять различных состояний блокировок и
соединение не зависимо от того, чем оно занимается, всегда находится
в одном из них.
Транзакции и состояния блокировок \nm изображены на рис.
.;+pic6-3
.
Рисунок раскрывает каждое возможное состояние блокировки, в которое может попадать
транзакция равно как и путь, которым транзакция может попасть в это
состояние на протяжении своей жизни.
Рисунок изображен в терминах состояний блокировок, блокировок транзакций и
жизненного цикла транзакций.
На рисунке действительно можно проследить жизнь транзакции в терминах блокировок.
.b
.;-
\begin {figure}[h]
\includegraphics[width=1.00\textwidth]{./m6_pics/f140_1.png}
\includegraphics[width=1.00\textwidth]{./m6_pics/f140_2.png}
\caption{Состояние блокировок в транзакциях SQLite}\label{pic6-3}
\end {figure}
.;-

.^
За исключением состояния транзакции
UNLOCKED,
каждое из них имеет соответствующую блокировку.
Таким образом, можно говорить, что соединение имеет
'блокировку в состоянии RESERVED',
или соединение находится 'в состоянии
RESERVED'
или просто 'в
RESERVED' -
это все значит одно и тоже.
За исключением
UNLOCKED, чтобы находиться в каком-то состоянии, соединение
сначала получает блокировку соответствующую этому состоянию.
.^
Транзакция может начинаться или с
UNLOCKED,
или
RESERVED или
EXCLUSIVE.
По умолчанию,
как видно на
.;+pic6-3
, транзакция начинается с
UNLOCKED.
Состояния блокировок из белых прямоугольников -
UNLOCKED,
PENDING,
SHARED
или
RESERVED - могут существовать в БД при
отсутствии соединений с последней.
Starting with PENDING in gray, however, things becomes more restrictive.
.;--------\

Состояние PENDING в сером прямоугольнике представляет
блокировку, которую держит одиночное соединение, назовем его писателем, желающее
получить состояние EXCLUSIVE.
И напротив,
Состояние PENDING в белом прямоугольнике представляет собой способ, которым
соединения требуют и освобождают блокировку, чтобы получить состояние SHARED.
Не взирая на все представленные состояния блокировок, каждая транзакция в \nm
сводится к одному из двух типов:
к транзакциям, которые читают; или
к транзакциям, которые пишут.
В конце концов этот факт отражен на рисунке:
как общаются друг с другом
читающие и пишущие транзакции.


.;3 Read Transactions
.3 Читающие Транзакции
.^
Сначала просмотрим процесс блокировки оператора $select$.
Этот процесс идет очень простым путем.
Соединение, которое выполняет оператор $select$,
меняется от
UNLOCKED к SHARED и, по достижении оператора $commit$, возвращается к
UNLOCKED. Конец истории.
.^
Теперь, поинтересуемся, что случится при выполнении двух операторов?
Какой станет блокировка в этом случае?
Ответ зависит от использования или не использования режима автокомита.
Рассмотрим следующий пример:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p141_1.png}
.;-
Сейчес, с явно заданным $begin$, два оператора $select$ выполняются
в одиночном соединении и, поэтому, выполняются в одном состоянии SHARED.
Первый вызов функции $exec()$ заканчивается, оставляя соединение в SHARED,
затем вызывается следущая $exec()$.
Наконец, явно выполненный оператор $commit$ переводит соединение
из SHARED обратно в UNLOCKED.
Все изменения блокировки выглядит следующим образом:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p141_2.png}
.;-
Теперь рассмотрим случай, как будто бы в примере нет ни оператора $begin$, ни оператора $commit$.
Это означает, что два оператора $select$ выполняются в режима автокоммита.
Тогда соединение для каждого из них проходит полный цикл изменений своего состояния.
Для этого случая блокировка меняется следующим образом:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p141_3.png}
.;-
Так как в примере просто читаются данные, это не выглядит совсем уж по другому,
но в режиме автокоммита таки приходится пройти дважды через блокировку файла.
И, как будет вскоре понятно, писатель может встрять между двумя оператора $select$
и изменить БД между вызовами. Таким образом, нельзя быть уверенным,
что эти два оператора вернут один и тот же результат.
C другой стороны, гарантируется, что при использовании $begin .. commit$
отношения результаты будут идентичными.
.3 Write Transactions
.3 Пишущие Транзакции
.^
Теперь рассмотрим оператор, который пишут в БД, такой как $update$.
Во первых, соединение должно менять свое состояние
так же как и в случае $select$ и закончится на состоянии SHARED.
Любая операция - все равно, читающая или пишущая - должна начинаться
с последовательного изменения
UNLOCKED $\rightarrow$ PENDING $\rightarrow$ SHARED,
причем PENDING, как будет вскоре видно, является основной блокировкой.


.;4 The Reserved State
.4 Состояние RESERVED
.^
В момент, когда соединение пытается записать что нибудь в БД, оно
свое состояние SHARED меняет на RESERVED.
И начать менять содержимое БД соединение сможет, если
блокировка RESERVED таки получена.
Даже если и не удастся на деле изменить содержимое БД в этот момент,
эти изменения сохранит
.x ?pager менеджер страниц
в упомянутом ранее
.x ?pgch кэше страниц.
Именно у этого кэша менялся размер в
разделе
.;+m4-conf
.
.^
После перехода соединения в состояние RESERVED,
менеджер страниц инициализирует
журнал откатов (rollback journal).
.x журнал откатов
.x rollback journal
Как показано на рис.
.;+pic6-1
, это файл, который используется для откатов и восстановлений после краха.
В частности, он хранит необходимые для восстановления страницы БД в состоянии,
которое они имели перед началом транзакцией.
В этот файл страницы, изменяемые B-деревом, складирует менеджер страниц.
В данном случае, для каждой записи, измененной оператором $update$,
менеджер страниц выбирает из БД страницу, содержащую исходную запись и сохраняет
её в журнале.
То есть, журнал хранит частичное содержание БД до транзакции.
Следовательно, все что менеджер страниц должен сделать для отката любой транзакции,
это просто скопировать содержимое журнала обратно в файл БД.
Тогда БД восстановит свое состояние перед транзакцией.
.^
Для состояние
RESERVED
существует три набора страниц, которыми управляет менеджер страниц;
измененные, не измененные и сохраненые в журнале.
Измененные страницы - это страницы, которые содержат записи, которые отредактировало B-дерево.
Они хранятся в кэше страниц.
Не измененные страницы - это страницы, которые B-дерево прочитало, но не меняло.
Это результат работы операторов $select$.
Наконец. страницы, сохраненные в журнале - это исходные версии отредактированных страниц.
Они сохраняются не в кэше страниц, а записаны в журнал перед,собственно, их изменением.
.^
Кэш страниц позволяет пишущему соединению закончить свою работу, находясь в состоянии
RESERVED
без конфликтов с другими читающими соединениями.
То есть, \nm эффективно справляется с одновременно работающими, несколькими читающими
соединениями и одним пищущим.
Хитростью есть то, что пишущее соединение хранит свои изменения в кэше страниц, а не в БД.
Запомним, что в один момент времени для данной БД только одно соединение может быть
в состоянии
RESERVED
или EXCLUSIVE - то есть, несколько читающих соеднинений и только одно пишущее.


.;4 The Pending State
.4 Состояние PENDING
.^
Когда соединение завершает все изменения оператора $update$
и приближается время фиксации транзакции,
менеджер страниц пытается перейти к состоянии блокировки EXCLUSIVE.
Ради полноты картины повторим изложенное в разделе
.;+blockDB
Манеджер страниц пытается получить
блокировку состояния PENDING из состояния
RESERVED.
Если ему это удается, он находится в нем, предотвращая
все другие соединения от перехода в это состояние.
Взгянув на
.;pic6-3
можно увидеть произведенный эффект.
Напомним, что важность блокировки PENDING уже отмечалась.
Теперь понятно почему.
Так как пишущее соединение находится в состоянии PENDING,
ни одно из других соединений не может больше перейти в состояние SHARED из состояния UNLOCKED.
Это означает, что теперь не появится ни одного нового соединения с БД;
ни читающего, ни пишущего.
Это состояния явлется отсеивающим действием.
Оно гарантирует, что не зависимо от времени ожидания, пишущее соединение дождется своего.
Продолжать свою работу как обычно смогут только те соединения, которые находятся в состоянии SHARED.
А пишущее соединение, находясь в PENDING, ожидает их окончания и освобождения их блокировок.
Вскоре, в секции
.;+m1-5-5
будет указано на дополнительные вопросы происходящие во время ожидания блокировок.
,^
После освобождения всеми соединениями их блокировок, БД переходит в монопольное владение к пишущему
соединению. Значит менеджер страниц может поменять состояние блокировки своего соединения из PENDING
в EXCLUSIVE.
.;---- 666666
26 июл 18, 16:47    [21605280]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
писатель может встрять остановиться между двумя операторами $select$ и изменить БД между вызовами в это время произойдет изменение БД в другом соединении

И соединение сможет начать менять содержимое БД соединение сможет, если блокировка RESERVED таки получена.

Для состояниея RESERVED

Это состоянияе является отсеивающим действием.
27 июл 18, 08:27    [21606780]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
автор
писатель может остановиться между двумя операторами $select$


--
та ну.
писатель может успеть сработать между двумя операторами $select$
27 июл 18, 10:16    [21607121]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
tchingiz
автор
писатель может остановиться между двумя операторами $select$


--
та ну.
писатель может успеть сработать между двумя операторами $select$

Да, не заметил что речь о внешнем писателе. Думаю как-то так надо "Другой писатель может успеть ..."
27 июл 18, 10:45    [21607219]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
меня этот писатель вообще раздражает

автор
И, как вскоре будет понятно,
другое соединение может успеть сработать между двумя операторами $select$
и изменить БД.
27 июл 18, 12:36    [21607853]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
+

.;---- 666666

.;4 The Exclusive State
.4 Состояние EXCLUSIVE
.^
В состоянии EXCLUSIVE, главное задание
заключается в переносе изменённых страниц из кэша страниц в файл БД.

.;Все становится более ответственным, так как менеджер страниц
.;собирается в действительности изменять БД.
Пеоед началом записи этих страниц, он обращается к журналу.
Он убеждается, что все содержимое журнала уже записано на диск.
В этот момент очень вероятно, что хотя менеджер страниц уже
записал нужное в файл журнала, операционная система буферизовала многие, если не все из них в оперативной
памяти.
В этот момент начинает
использоваться,
описанная в разделе
.;+m4-conf
прагма синхронизации - $synhronous$.
Метод, заданный прагмой, определяет насколько тщательно менеджер страниц
обеспечивает вывод операционной системой страниц журнала на диск.
Нормальное установка заключается в выполнении полной синхронизации перед
продолжением работы, операционная система должна подтвердить реальную запись
всех буферизованных страниц журнала на поверхность диска.
Если прагма $synhronous$ установлена в $FULL$,
менеджер страниц выполняет две полных синхронизации перед продолжением.
Если прагма $synhronous$ установлена в $NONE$, менеджер страниц
не заботится о журнале вообще (и раз он может быть в 50 раз быстрее, можно
забыть о надеждности транзакций).
.^
Журнал это единственная возможность восстановить файл БД после краха приложения или операционной системы в момент
записи в БД менеджером страниц, поэтому фиксация журнала на диске так важна.
Невозможно вернуть БД в начальное состояние, так как страницы, не перенесенные из оперативной
памяти на диск перед крахом системы оказываются потерянными навсегда.
В лучшем случае, БД окажется в несогласованном состоянии, в худшем - файл окажется испорченным.
.! Внимание
Даже если было использовано наиболее консервативное значение
для прагмы $synhronous$ журнал может все таки не полностью сбросится на диск.
Это не вина \nm, это следствие определенных типов аппаратных средств или операционных систем.
\nm использует системный вызов $fsync()$ под Юниксами и $FlushFileBuffers()$ под Windows чтобы
заставить записать страницы журнала на диск. Однако есть сообщения о том, что эти функции не всегда
работают, особенно на дешеввых IDE дисках. По всей видимости, некоторые производители IDE дисков
используют микросхемы, которые привирают о реальном состоянии дел при записи.
В некоторых случаях микросхемы кешируют данные и сообщают что они уже записаны на поверхность диска.
Кроме этого, есть сообщения (непровереные) о том, что Windows иногда игнорирует вызовы $FlushFileBuffers()$.
Таким образом, в случае сомнительных программных или аппаратных средств надежность транзакций может пострадать.
.!
.^
Как только менеджер страниц позаботился о журнале, он копирует все измененные страницы в файл БД.
Что произойдет потом, записит от режима транзации.
В случае автофиксации транзакций менеджер страниц очищает журнал и кэш страниц, переходит
из состояния EXCLUSIVE в UNLOCKED.
Если транзакция не добралась до фиксации, то менеджер страниц продолжает держать состояние блокировки EXCLUSIVE
и журнал используется до достижения либо оператора $commit$, либо оператора $rollback$.




.;4 Autocommit and Efficiency
.4 Автофиксация и Производительность
.^
С полученным багажем знаний, рассмотрим чем отличается оператор $update$, выполняемый в явной транзакции,
от оператора $update$, выполняемого в режиме автофиксации.
При автофиксации каждая команда, изменяющая БД в отдельной транзацкии последовательно
меняет свои состояния следующим образом:

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p143_1.png}
.;-
.^
При этом, каждый такой цикл включает в себя создание, фиксацию и очистку журнала откатов.

Несмотря на то, что выполнение нескольких выборок в режиме автофиксации
не является проблемой с точки зрения эффективности,
необходимо тщательно обдумать использование автофиксации для частых запросов на запись.

Ведь, как упоминалось в случае $select$, при выполнении несколькоих операторов с автофиксацией,
ничто не сможет удержать другое работающее соединение от изменения БД между операторами.
По этой причине, еесли два обновления БД зависят от заданных значений в данных, требуется всегда выполнять их в
одной и той же транзакции.
.= Блокировки и восстановление
.^
В \nm реализация блокировок использует обычный файл блокировки.
\nm есть три различных файла блокировок для файла БД: резервированный байт (reserved byte),
байт ожидания (pending byte) и разделяемая область (shared region).
.x резервированный байт
.x reserved byte
.x байт ожидания
.x pending byte
.x разделяемая область
.x shared region

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p144_1.png}
.;-
Все начинается с байта ожидания.
Чтобы перейти от состояния UNLOCKED к SHARED
соединение пробует взять блокировку для чтения на байте ожидания.
.;------- хрень какаято to get a read-lock on the pending byte.
В случае успеха, соединение берет блокировку для чтения на случайном байте в разделяемой области
и возвращает блокировку для чтения на байте ожидания.
Чтобы изменить состояние от SHARED к RESERVED, соединение вытается получить блокировку записи
для байта ожидания. В случае успеха, это приводит к процессу истощения, так как не позволяет
другим соединениям брать блокировку для чтения на байте ожидания, чтобы перейти к состоянию SHARED.
Наконец, чтобы изменить состояние своей блокировки на EXCLUSIVE, соединение
пробует получить блокировку для чтения на всей разделяемой области.
Так как разделяемая область содержит блокировки для чтения всех остальных активных соединений, этот
шаг гарантирует, что блокировка соединения перейдет в состояние EXCLUSIVE только после того,
как сначала все другие блокировки соединений освободят состояние SHARED.
.b
Механизм восстановления после краха в \nm использует резервированный байт
чтобы определить требуется ли восстановление БД,
Так как файл журнала и блокировка RESERVED передается из рук в руки, менеджер
страниц видит журнал без блокировки,
.; if the pager sees the former without the latter, ------
если случилось что то плохое.
Такая проверка целостности выполняется каждый раз, когда менеджер
страниц открывает БД или пытается получить страницу из неё.
Наличие файла журнала и отсутствие блокировки RESERVED на БД означает,
что процесс, создавший журнал потерпел крах или упала операционая система.
В этом случае журнал называет горячим журналом и считается что БД может находится
в противоречивом состоянии.
Такой журнал должен быть 'отыгран назад',
чтобы восстановить то состояния БД, которое было перед прерыванием транзакции.

.b
Для этого менеджер страниц переводит БД в режим восстановления.
Для этого, как показано выше (и на рис.
.;+pic6-3
) менеджер изменяет свое состояние от SHARED прямо к PENDING.
Такой переход возможен только в єтой ситуации.
Есть две причины, чтобы пропустить состояние RESERVED.
Во-первых, блокирование байта ожидания не допускает никаких новых соединений с БД.
Во-вторых, уже существующие соединения с БД (в состоянии SHARED) при следующей
попытке доступиться к странице увидят, что журнал горячий.
Такие соединения тоже попробуют перейти в режим восстановления и отыграть журнал.
Однако не смогут сделать это, так как первое соединение уже захватило блокировку PENDING.
То есть, немедленно меняя блокировку SHARED на PENDING, первое соединение
может быть уверенно, что новых соединений с БД не появится,
соединения с БД уже находящиеся в состоянии SHARED не смогут начать восстановление БД.
Работа всех, кроме начавшего восстановление соединения, приостановлена.
.b
В основном, горячий журнал являетя неявной блокировкой EXCLUSIVE.
После краха пишущего соединения в БД невозможна никакая активность до тех пор,
пока одно из соединений не восстановит её. При попытке доступа к любой странице
следующий менеджер страниц увидит горячий журнал, блокирующий все и начнет восстановление.
При отсутствии активных соединений, горячий журнал обнаружит первое приложение, попытавшееся соединяться с БД.
Оно же и начнет восстановление.
.=

.;2 +m1-5-4 Tuning the Page Cache
.2 +m1-5-4 Настройка Кэша Страниц
.^
Предположим, предыдущий пример был изменен, теперь он начинается с
оператора $begin$, за которым следуют $update$.
Причем в процессе всех изменений переполняется кэш страниц.
Как на это отреагирует \nm?
То есть, $update$ потребует хранить больше страниц, чем может поместиться в кэше страниц.
Что теперь произойдет?


.;3 Переход в Состояние EXCLUSIVE
.3 Transitioning to Exclusive
.^
Что конкретно делает менеджер страниц, меняя состояние RESERVED на EXCLUSIVE и почему?
Существует два сценария и будут рассмотрены оба из них.
Либо соединение достигает момента фиксации изменений и явно начинает
блокировку EXCLUSIVE, либо кэш страниц переполняется без возможности какого либо выбора.
Рассмотрим первый сценарий.
Что случается при заполнении кэша страниц?
Выражаясь простым языком, менеджер больше не может запомнить ни одной измененной страницы и, естественно,
не может выполнять свою работу.
Его переводят в состояние EXCLUSIVE, чтобы продолжать.
На деле, это не совсем правда, потому что существуют мягкий и жесткий пределы.
.^
.;-------
Первому заполнению кэша страниц соответствует мягкий предел.
В этот момент кэш хранит смесь из неизмененных и измененных страниц.
Менеджер страниц пытается очистить кэш. Он проходит по кэшу избавляясь от неизмененных страниц.
После очистки менеджер продолжать работу с памятью до тех пор, пока кэш не заполнится снова.
Далее, если есть хоть одна неизмененная страница, можно повторить процесс очистки от них.
Это означает появление жесткого предела.
В этот момент менеджер страниц не имеет другой возможности, кроме как переходить к состоянию EXCLUSIVE.
.^
С ругой стороны, прагма $cach\_size$, проявляется в состоянии RESERVED.
Как объяснялось в секции
.;+m4-conf
, прагма управляет размером кэша страниц.
Чем больше кэш, тем больше измененных страниц в нем может запомнить менеджер страниц и
тем больше работы соединение может выполнить, не меняя свое состояние на EXCLUSIVE.
И, как отмечалось выше, выполнение работы в состоянии RESERVED уменьшает время, когда соединение находится
в состоянии EXCLUSIVE.
Если все закончено в RESERVED, то EXCLUSIVE нуже исключительно на время сбрасывания
измененных страниц на диск, не для компиляции следующих запросов, и обработки результатов и, затем, вывода на диск.
.; overall concurrency ------??.
Обработка, которыя выполняется в состоянии RESERVED, может значинельно улучшить общую производительность.
При больших транзакциях, перегруженной БД и доступной памяти было бы идеально, чтобы размер кэша
позволял находиться соединению в RESERVED так долго как возможно.


.3 Выбор Размера Кэша
.;3 Sizing the Page Cache
.^
Итак, как подобрать размер кэша?
Это зависит от выполняемой работы.
Поедположим, требуется поменять каждую запись в таблице $episodes$.
В этом случае каждая страница таблицы будет изменена.
То есть, надо узнать размер таблицы $episodes$ в страницах и соответственно
изменить размер кэша страниц.
Для получения такой информации о таблице $episodes$ требуется
использовать sqlite3\_analyzer.exe.
Для каждой таблицы он может вывалить детальную статистику, включая считчик
страниц. К примеру, для таблицы $episodes$ из БД $foods$ можно получить
следующую информацию:

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p146_1.png}
.;-
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p146_2.png}
.;-
Общее число страниц таблицы - 5. Четыре страницы действительно отведено под
таблицу, и одна - под индекс.
Поскольку умолчательный размер кэша - 2000 страниц, то волноваться не о чем.
В таблице 400 записей, следовательно, каждая страница хранит 100 записей.
Не зачем беспокоится об изменении кэша, до тех пор, пока не придется менять каждую из, по меньшей мере,
196 000 записей
в таблице $episodes$.
И, вообще, этим нужно заниматься при нескольких соединениях с БД и
решении вопроса конкуренции.
Для одиночного пользователя БД это все не имеет значения.



.;2 +m1-5-5 Waiting for Locks
.2 +m1-5-5 Ожидание Блокировок
.^
Ранее упоминался менеджер страниц, ожидающий смену состояния с PENDING
на EXCLUSIVE.
Но что конкретно подразумевает это ожидание блокировки?
.;-----What exactly is involved with waiting on a lock?
Во-первых, ожидание блокировки может повлечь любой вызов $exec()$ или $step()$.
Всякий раз, когда \nm натыкается на ситуацию, когда он не может получить блокировку, умолчательным поведением
является возврат признак SQLITE\_BUSY в фукнцию, которая её просит.
Признак SQLITE\_BUSY можно получить не зависимо от исполняемого оператора.
Как уже известно, даже оператор $select$ может сбойнуть на попытке получить блокировку SHARED,
если пишущее соединение пишет или находится в состоянии PENDING.
Самое простое, что можно сделать поосле получения SQLITE\_BUSY - это повторить предыдущий вызов.
Однако, вскоре будет ясно, что это не всегда лучший способ поведения.

.;3 Using a Busy Handler
.3 Испльзование Обработчика Занятости

.^
Вместо циклического вызова функций снова и снова, можно использовать
обработчик занятости (busy handler).
.x обработчик занятости
.x busy handler
Вместо упорного вызывания функций, возвращающие SQLITE\_BUSY, когда соединение не может получить блокировку,
лучше начать использовать обработчик занятости.
.^
Обработчик занятости - это функция, которую пишут, чтобы убить время. Она может делать что либо ещё, вроде
заботливой рассылки спама тещам. Обработчики занятости предполагается вызывать, когда \nm не может
получить блокировку.
Единственное, что обязан сделать обработчик это предоставить код возврата, уведомляющий \nm о
требуемых следующих действиях.
Если обработчик возвращает true, то \nm
будет продолжать попытки получить блокировку.
.;----------
Если обработчик возвращает false, то \nm вернет SQLITE\_BUSY
в функцию. запрашивающую блокировку.
Рассмотрим следующий пример:

.;----------7777

28 июл 18, 10:46    [21610134]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
В состоянии EXCLUSIVE, главное задание заключается в переносе происходит сохранение изменённых страниц из кэша страниц в файл БД.

Пеоред началом записи этих страниц

В этот момент очень вероятно возможно, что хотя менеджер страниц уже записал нужное нужные страницы в файл журнала, но операционная система ...

(и раз при этом он может быть в 50 раз быстрее, но можно забыть о надеждности транзакций).

на дешеввых IDE дисках

Что произойдет потом, запвисит от режима транзакции.

соединение пробует взять установить блокировку для чтения на байте ожидания.
ИМХО тут автор попытался кратко описать устройство механизма блокировок, но у него это не получилось, а получились непонятные обрывки подробностей.

С другой стороны, прагма $cach\_size$,

Обработка, которыая выполняется в состоянии RESERVED,

возврат признак SQLITE\_BUSY в функнцию

Самое простое, что можно сделать поосле

.3 Использование Обработчика Занятости
28 июл 18, 17:11    [21610662]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T
соединение пробует взять установить блокировку для чтения на байте ожидания.
ИМХО тут автор попытался кратко описать устройство механизма блокировок, но у него это не получилось, а получились непонятные обрывки подробностей.

угу, я лелеял надежду, что ты понял что там написано, пока продирался через эту ахинею.

надо еще долго перечитывать


автор
.;----------7777

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p147_1.png}
.;-
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p147_2.png}
.;-
Собственно, разработка функции $spam\_mother\_in\_law()$ остается как упражнение для читателя.
.^
Функция $step()$ должна получить блокировку SHARED в БД, чтобы выполнить оператор $select$.
Предположим, с этой БД есть еще активное пишущее соединение. Тогда обычно функция $step()$ возвращает
SQLITE\_BUSY. Однако в нашем случае это не так.
Здесть менеджер страниц (тот из них, который обращается за блокировкой) вместо этого вызывает функцию $busy()$,
так как она была зарегистрирована в качестве обработчика занятости.
$busy()$ увеличивает счетчик $counter$, посылает теще сотню случайных писем
из своей папки со спамом и возвращает 1. Менеджер страниц интерпретирует её как true (сигнал продолжать захватывать блокировку)
и повторяет попытку получить
блокировку SHARED.
На этот раз, $busy()$ возвращает 0, который воспринимается как false.
Тогда менеджер страниц, вместо повторения захвата блокировки, возвращает код SQLITE\_BUSY, которым
закончится работа функции $step()$.
.^
Разрабатывать обработчик занятовсти просто для ожидания (чтобы убить время) нет нужды.
Он уже есть в программный интерфейс \nm. Это функция, которая просто засыпает на заданный период времени для ожидания
блокировки. Её название $sqlite3\_busy\_timeout()$ и поддерживается библиотеками некоторых языков расширений.
По существу можно просто сказать 'засни на 10 секунд, если не сможешь получить блокировку'
и менеджер страниц сделает это. Он подождет 10 секунд, и затем, если не сможет получить блокировку, вернет SQLITE\_BUSY.


.;3 Using the Right Transaction
.3 Правильное Использование Транзакций
.^
Ещё раз пересмотрим предыдущий пример, но теперь в нем заменим оператор $select$, на оператор $update$.
Что на деле будет означать SQLITE\_BUSY?
После применения $select$ это просто значит: 'Я не могу получить блокировку SHARED'.
А что это значит в случае $update$?
На деле, это неизвестно.
SQLITE\_BUSY может означать, что соединение не смогло получить блокировку SHARED, в связи
с наличием другого пишущего соединения в состоянии PENDING.
Это может означать, что соединение, получив SHARED, не может получить RESERVED.
Отличие в том, что не известно состояние БД или состояние рассматриваемого соединения.
SQLITE\_BUSY для запросов на запись полностью неопределен в
режиме автофиксации.
Итак, что же теперь делать дальше?
Надо ли вызывать $step()$ снова и снова, пока оператор не выполнится?
.^
над этим надо подумать.
Предположим, попытка получить блокировку SHARED, а не RESERVED,
закончилась SQLITE\_BUSY и теперь соединение удерживает состояние
RESERVED.

.:++++ Suppose SQLITE_BUSY was the result of you getting a SHARED lock but not RESERVED,
.:++++ and now you are holding up a connection in RESERVED from getting to EXCLUSIVE.

Напомним, состояние БД - не известно.

И нахрапистая попытка любой ценой выполнять свою транзакцию не обязательно завершится удачей,
и в рассматриваемом соединении, и в любом другом.
Попытки вызова $step()$ заведут в тупик -- в задницу соединения в состоянии RESERVED,
и, если никто из двоих не сбойнет, к клинчу.
.= Замечание
\nm пытается избежать клинча в конкретно этом сценарии, игнорируя вызов обработчика занятости (busy handler),
.x обработчик занятости
.x busy handler
.;++++
Обработчик занятости соединения в состоянии SHARED не вызывается, если предполагается, что
он будет мешать завершиться соединению в состоянии RESERVED.
.;++++ However, it is up to the code to get the hint.
Приложение может просто продолжать вызывать $step()$, и, в этом случае,
ничто не спасет \nm
.=
Поэтому запрос на запись надо начинать с $begin immediate$.
По крайней мере, при получении ответа SQLITE\_BUSY, будет известно состояние соединения.
Пишущее соединение сможет повторять свои попытки без блокирования другого соединения.
И известно, что при достижении успеха, пишущее соединение переходит в состояние RESERVED.
.;Now you can use brute force if you have to because you are the one in the right.
Теперь можно делать что угодно.
С другой стороны, $begin immediate$ является гарантией что не придется иметь дела с условиями занятости вообще.
Но при этом надо помнить, что пишущее соединение находится в состоянии EXCLUSIVE, которое
снижает эффективность многократных соединений, по сравнению с работой в состоянием RESERVED.
.=
.4 Блокировки и Сетевая Файловая Система
.^
Теперь можно иметь хорошее представление о трудностях
использования файла ДБ через сетевую файловую систему (в расшаренном каталоге).
\nm поддерживает многократные соединения размещая файл блокировки в файловой системе.
Очень важно, чтобы этот файл и размещался и удалялся в правильные моменты времени.
Корректность управления блокировками многократных соединения у \nm полностью зависит от файловой системы.
Под Unix \nm использует POSIX advisory locks, а под Windows - OS X и системные вызовы $LockFile()$ $LockFileEx()$$UnlockFile()$.
Эти стандартные системные вызовы корректно работают в несетевой файловой системе.
Сетевая файловая система эмулирует работу обычной. И, к сожалению, в некоторых реализациях эта
эмуляция не всегда корректна. Даже в случае корректной работы сетевой файловой системы
остаются поводы для размышлений.
.^
Возьмем к примеру NFS. Это отличная сетевая файловая система.
Однако, исходная реализация NFS имеет известные ошибки и, в некоторых случаях, не имеет реализованніх блокировок.
Это означает серьезную проблему для \nm. Без блокировок два соединения могут перейти в состояние EXCLUSIVE
на одной ДБ и в одно время, что приведет к определенным нарушениям целостности.
Это не проблема NFS вообще, это проблема некоторых её реализаций.
Благодаря последним реализациям NFS эти трудности преодолены и некоторые из них (такие, которые используются в Sun)
вполне работоспособны.
.; в виндюках это не надо



.;2 +m1-5-6 Code
.2 +m1-5-6 Прикладные Программы
.^
Наконец, получена хорошая картина для программного интерфейса, транзакций и блокировок.
Чтобы покончить с этим, рассмотрим все это с точки зрения прикладной программы и
рассмотрим пару сценариев, которые было бы желательно обсудить.


.;3 Using Multiple Connections
.3 Использование Нескольких Соединений
.^
Опытные программисты могут написать приложение, использующее несколько соединений.
Классический пример: одно соединение проходит по таблице в то время, как другое изменяет её.
Такие приожения могут приводить к трудностям в работе \nm, поэтому их надо
аккуратно обдумывать.
Рассмотрим пример:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p149_1.png}
.;-
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p149_2.png}
.;-
.; we bet
Можно спорить, что здесь легко указать трудность.
Находясь в цикле $while$, соединение $c2$ выполняет обновления таблицы, в то время как
соединение $c1$ имеет блокировку в состоянии SHARED.
Эта блокировка не будет освобождена до финализации оператора $stmt$ после цикла.
Таким образом, нет никакой возможности выполнить запрос обновления БД внутри цикла.
Либо $c2.exec()$ будет тихо сбоить, либо, в случае обработчиков занятости, они будут просто тормозить приложение.
Более правильная версия этого примера должна использовать одно соединения и выполнять запросы в рамках
транзакции $begin immediate$. Новую версию приводим ниже:

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p149_3.png}
.;-
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p150_1.png}
.;-
.^
В подобных случаях надо использовать операторы из одного соединения для запросов чтения и записи.
Тогда не зачем беспокоиться о трудностях, вызываемых блокировками БД.
Но, как оказывается, этот конкретный пример остается нерабочим.
.;----- ????
Процесс блокирование при чтение таблицы одним оператором и редактирование её другим
имеет дополнительную тонкость, которую тоже надо знать.
Сейчас она будет раскрыта.
.;3 The Importance of Finalizing
.3 Важность Финализации
.^
Обычной промашкой в обработке оператора $select$ является непонимание того,
что блокировка SHARED не обязательно освобождается при вызове фунгкции $finalize()$ ( или $reset()$),
более того, обычно не освобождается.
.; +++++ переспросить
Рассмотрим пример:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p150_2.png}
.;-
Хотя так программы на практике не пишут, это можно написать случайно,
просто потому, что так можно сделать.
.;++++ you might end up doing it anyway by accident simply because you can get away with it.
Эквивалент этого примера, написанный с помощью программного интерфейса C,
будет на деле работать. Даже если не вызвать $finalize()$, второе соединение изменит БД
безо всяких проблем. Прежде чем сказать почему, взглянем на следующий пример:


.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p150_3.png}
.;-
Предположем в таблице $episodes$ есть 100 запией. Приложение прошло только
три из них. Что случиться теперь?
Вторе приложение получит SQLITE\_BUSY.
.^
В предыдущем примере, \nm освобождает блокировку SHARED, когда оператор
достигает окончания отношение результата.
То есть, в момент последнего вызова $step()$, на котором программный интерфейс C возвращает SQLITE\_DONE,
VDBE встреить инструкцию $Close$ и \nm закроет курсор и сбросит блокировку SHARED.
То есть, $c2$ будет иметь возможность выполнить свой $insert$
.; не было инсерта был апдайет ------
хотя $c1$ еще не вызвал $finalize()$.
.^
Во втором случае, оператор $select$ не достиг последней записи из отношения результата.
Поэтому следующий выхов $step()$ должен вернуть SQLITE\_RESULT,
что означает наличие непрочитанных записей в отношении результате, это же означает,
что блокировка SHARED остается.
Значит, $c2$ не может из - за неё выполнить $insert$.
.; на деле $update$
.^
Мораль этой истории в том, что не надо делать все, что можно. Вызовать $finalize()$
или $reset()$ перед запросами на редактирование нужно всегда, когда есть другие соединения.
Также хорошо бы помнить, что $step()$ и $finalize()$ в режиме автофиксации
более или менее ограничивают транщакции и блокировки.
Они начинают и заканивают транзакции. Они начинают и освобождают блокировки.

.; ++++++
.; The other thing to remember is that in autocommit mode step() and finalize()
.; are more or less transaction and lock boundaries
Нужно очень аккуратно работать в другом соединении между этими двумя функциями.



.3 Режим Разделяемого Кэша
.;3 Shared Cache Mode
.^
Теперь, когда все понятно про правила работы конкурирующих соединений, настало время для некоторого усложенния.
\nm имеет еще одну модель для конкурирующих соединений, которая называется режим разделяемого кэша.
Она относится (регулирует / позволяет??) к работе соединений внутри отдельных нитей.
.;++++
.^
В этом режиме нити могут создавать несколько соединений, которые сообща используют (разделяют) один и тот же самый кэш страниц.
.x разделяют
.x сообща используют
Более того, такая группа соединения может иметь несколько читающих соединений и одно пишущее (в состоянии EXCLUSIVE),
работающих в одно время с одной и той же БД. Уловкой есть то, что
эти соединения из разных нитей не могут разделять кэш, они строго ограничены одной нитью (именно работающей в
режиме разделяемого кэша), создавшей их. Более того, пишущие и читающие соединения должны быть готовы
обрабатывать специальные условия включающие блокировку таблиц.
.^
Когда читающие соединения читают таблицы, \nm автоматически создает блокировку таблиц для них.
Это предохраняет таблицы от изменения пишущим соединением. Если пишущее соединение пытается
изменить таблицу, заблокированную для чтения, то получает SQLITE\_LOCKED.
Та же логика применяется к читающим соединениям, пытающимся обратиться к таблицам заблокированным для записи.
Однако в этом случае, читающие соединнения могут идти далее и читать таблицы, которые были изменены пишущим соединением.
Правда оно должно работать в специальном режиме (read-uncommitted mode) чтения не фиксированных данных.
.x read-uncommitted mode
.x режиме чтения не зафиксированных данных
Его можно задавать при помощи прагмы $read\_uncommitted$
.x read\_uncommitted
.x прагма read\_uncommitted
В этом случае \nm не ставит на таблицы блокировку чтения. Как результат, читающие соединения вообще не замечают
пишущее. Однако, тогда они могут получить несогласованные данные, так ак пишущее соединение может изменить
таблицы во время чтения. Этот режим похож на уровень изолирования транзацкий с названием грязное чтение.
.x грязное чтение
.^
Этот режим разработан для встраиваемых серверов, которые нуждаются в экономии оперативной памяти и
в легком усилении конкуренции в определенных ситауциях.
Дополнительную информацию о том, как использовать этот режим с программным интерфейсом для C можно найти в гл.
.;+m1-6
.




.;2 +m1-5-7 Summary
.2 +m1-5-7 Итого
.^
Программный интерфейс \nm гибкий, интуитивно понятный и легкий
в использовании.
Он состоит из двух основных частей: базовый интерфейс
и дополнительный. Базовый интерфейс вращается возле двух основных
структур данных, которые используются для выполнения команд SQL:
соединений (connection) и операторов (statement).
Операторы выполняются за три шага: компиляция, выполнение
и финализация. Функции SQL $exec()$ и $get\_table()$ выполняют эти
три шага за один вызов функции, автоматически обрабатывая объекты, ассоциированные
с операторами. Дополнительный интерфейс предоставляет возможности
для дополнительной настройки \nm треми способами: при помощи функций, определяемых
пользователем; при помощи групповых функций, определяемых пользователем; при помощи сортирующих последовательностей,
определяемых пользователем.
.^
Так как модель конкуренции в \nm несколько отличается от других СУБД, то важно иметь некоторое
понимание как \nm управляется с транзакциями и блокировками, как они на деле выполняются и
как они работают внутри кода пользователя.
Вообще говоря, эти концепции не трудны для понимания и состоят из нескольких простых правил,
которые необходимо помнить, чтобы разрабатывать программы с использованием \nm .
.^
Все, уже рассказанное выше, будет уточняться в последующих главах,
так как эти концепции применимы не только к программному интерфейсу для языка C,
но к другим языкам, поскольку они построены на использовании интерфейса для C.
28 июл 18, 17:58    [21610737]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
упс
28 июл 18, 17:59    [21610741]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T

В этот момент очень вероятно возможно, что хотя менеджер страниц уже записал нужное нужные страницы в файл журнала, но операционная система ...


я это все стер и переписал по своему.
автор
Так как менеджер страниц собираюет изменять БД, то лежащая на нем ответственность возрастает.
И работу эту надо сделать с максимальной тщательностью.
Перед началом вывода этих страниц в БД, он обращается к журналу.
От него требуется убедиться, что все содержимое журнала уже записано на диск (в его файле).
Вероятно, что
операционная система продолжает хранить многое, если не все в оперативной
памяти, несмотря на уже выполненные системные вызовы
От менеджера требуется еще раз (выполнив другие системные вызовы)
потребовать от неё завершить вывод этих страниц на поверхность диска в буквальном смысле.
28 июл 18, 18:20    [21610771]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
автор
.= Замечание
\nm пытается избежать клинча в конкретно этом сценарии, игнорируя вызов обработчика занятости (busy handler),
.x обработчик занятости
.x busy handler
.;++++
Обработчик занятости соединения в состоянии SHARED не вызывается, если предполагается, что
он будет мешать завершиться соединению в состоянии RESERVED.
.;++++ However, it is up to the code to get the hint.
Приложение может просто продолжать вызывать $step()$, и, в этом случае,
ничто не спасет \nm
.=

заменил на

автор
.= Замечание
\nm пытается избежать клинча в конкретно этом сценарии, игнорируя вызов обработчика занятости (busy handler),
.x обработчик занятости
.x busy handler
.;++++
Обработчик занятости соединения в состоянии SHARED не вызывается, если предполагается, что
он будет мешать завершиться соединению в состоянии RESERVED.
Однако, понята ли подсказка зависит полсностью от приложения.
.;++++ However, it is up to the code to get the hint.
В случае, если оно будет просто продолжать вызывы $step()$
ничто не спасет \nm.
.=

28 июл 18, 18:37    [21610793]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
ну, типа того
+

https://drive.google.com/open?id=1bFN4XNe4wiwxdEEEISXt47Ob2x2TWJ5M
28 июл 18, 19:11    [21610851]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
По чистовику
c.112 что бы (слитно пишется) понять
c.112 начинается со введения
c.112 основным подсистемами SQLite
с.113 базовый программный интрефейс и расшеиренный.
с.113 что бы (слитно пишется) разрабатывать
с.114 Рис. 6.1 отсутствует
с.115 The B-дерево и Менеджер Страниц
с.115 менеджер страниц что бы (слитно пишется) читать
с.115 Существует два важных метода для выполнения команд SQL: подготовленные запросы и wrapped запросы. Подготовленные запросы является Prepared queries are the way in which SQLite ultimately executes all commands, both in the API and internally. (надо бы все по-русски)
с.115 трех фазный (слитно пишется) процесс
с.116 существует две wrapper функции вроде решили их называть "немедленными" 21593584
с.116 для этого нужно использовать либо строчку ry :memory:
с.118 На рис. 6.2 изображены эти
с.120 значения для подставновки
с.120 связать новый набор значений со уже откомпилированным
с.120 Замечание переводчика В примере, по видимому, отсутствует вызов функции step()
с.120 Executing Wrapped Queries wrapped (надо бы все по-русски)
с.122 при использовании wrapped (надо бы все по-русски)
с.122 Formatting SQL Statements (надо бы все по-русски)
с.123 Атака при помощи SQL инъекции ИМХО слабовато выделено, в оригинале это вставки на сером фоне, а тут смотрится как очередной абзац
с.123 Приложение становится уязвимым для атакаи при помощи SQL инъ-екции, если будет полагаеться
с.123 Если не внимательно (слитно пишется) относиться
с.123 Operational Control (надо бы все по-русски)

Усталь, продолжение завтра :)
29 июл 18, 20:54    [21612431]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
с.124 Замечание переводчика В примере, по видимому,
с.124 для использования во много-поточныхой среде.
с.125 User-defined extensions must be registered on a connection-by-connection basis as they are stored in program memory (надо бы все по-русски)
с.127 объяснить в каком состоянии находится
с.128 это оазначает, что каждый оператор
с.130 Сейчеас, с явно заданным
с.130 6.3.4 Write Transactions (Похоже лишняя глава)
с.130 Теперь рассмотрим оператор, который пишует в БД,
с.131 которое они имели перед началом транзакциейии.
с.131 Для состояниея RESERVED существует
с.131 Хитростью есть является то, что пишущее соединение
с.132 состояниию блокировки EXCLUSIVE.
с.132 И теперь окаозывается задействованной
с.132 Нормальноеая установка заключается
с.135 6.4.1 Transitioning to Exclusive (надо бы все по-русски)
с.136 то EXCLUSIVE нужен исключительно
с.136 Пор-едположим, требуется
с.137 возврат SQLITE_BUSY в функцию, которая её просит. ??
с.138 Разрабатывать обработчик занятовсти
с.141 Процесс блокированиея при чтениеи таблицы
с.141 Предположеим в таблице
с.142 транщзакции и блокировки. Они начинают и заканчивают
с.142 Она относится (регулирует / позволяет??)
с.142 несогласованные данные, так как пишущее
с.143 тремия способа-ми:
30 июл 18, 09:52    [21613391]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T
По чистовику
c.112 что бы (слитно пишется) понять
Усталь, продолжение завтра :)

грепом нашел 27 вхождений неправильного что бы и заменил
)))
31 июл 18, 15:23    [21618430]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
Dima T,
автор
с.123 Атака при помощи SQL инъекции ИМХО слабовато выделено, в оригинале это вставки на сером фоне, а тут смотрится как очередной абзац


наконец, узнал как менять фон
31 июл 18, 18:53    [21619170]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
большую часть пофискил.
автор
Executing Wrapped Queries wrapped (надо бы все по-русски)

с этим я пока подожду, чешутся руки
переписать эти объяснения.
После консультаций с White Owl, мне кажется
надо не операторы делить на подготавливаемые и немедленно выполняемые,
а функции из апи поделить на две группы :
группа, которая подготавливает операторы
и группа, которая немедленно выполняет операторы.
31 июл 18, 19:58    [21619278]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
+
https://drive.google.com/open?id=12MSRy_dc7uoKAEuJcbzIKN7J72CqvKT6
31 июл 18, 20:06    [21619291]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
все больше глобальных изменений не будет
+

https://drive.google.com/file/d/10XPFuUPYgzxuO5cwhdnqsse3p1QqO-vs/view?usp=sharing
8 авг 18, 12:20    [21634151]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
tchingiz
все больше глобальных изменений не будет
+

https://drive.google.com/file/d/10XPFuUPYgzxuO5cwhdnqsse3p1QqO-vs/view?usp=sharing

Погуглил "SQLite на русском" этот топик второй в выдаче гугла, но мало кто до конца долистает.
Модераторы, продублируйте как-нибудь ссылку tchingiz в первом посте. Мы же старались ...
12 окт 18, 20:13    [21702916]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
ShSerge
Member

Откуда: ʚонɔ dиw
Сообщений: 24853
Dima T
...Модераторы, продублируйте как-нибудь ссылку tchingiz в первом посте. Мы же старались ...

Не понял. Что ты имеешь ввиду?
ПС. С удовольствием пропиарю (не паблик релейшын, а паже ранк) моего дорогого Чингиза.
12 окт 18, 20:50    [21702949]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
ShSerge, выше почитай.
12 окт 18, 20:55    [21702954]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
ShSerge
Member

Откуда: ʚонɔ dиw
Сообщений: 24853
Dima T
ShSerge, выше почитай.

Дай ссылку. Нифига не понял. Я этот топик уже читал. Для себя файл давно уже скачал.

ПС. Лёха - наше всё. Молодец таки.
12 окт 18, 21:26    [21702969]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
tchingiz
http://agp1.hx0.ru/.SQLite.Allow.pdf

перевод в процессе.
за указанные ошибки моя благодарность не будет знать границ в разумных пределах

с этим хостингом у меня возникли непреодолимые препятствия.
Оно уже года два не работает.
второй пост топика можно грохнуть
13 окт 18, 14:06    [21703269]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
Dima T
Member

Откуда:
Сообщений: 13939
tchingiz
tchingiz
http://agp1.hx0.ru/.SQLite.Allow.pdf

перевод в процессе.
за указанные ошибки моя благодарность не будет знать границ в разумных пределах

с этим хостингом у меня возникли непреодолимые препятствия.
Оно уже года два не работает.
второй пост топика можно грохнуть

ИМХО может вместо той ссылки приаттачить текущее состояние перевода отсюда 21634151 или на эту ссылку заменить если она постоянная.
13 окт 18, 14:57    [21703299]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
White Owl
Member

Откуда:
Сообщений: 12390
tchingiz,

Сделай новую тему с текущим статусом книги и правильными ссылками - прикреплю.
13 окт 18, 17:55    [21703342]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
ShSerge
Dima T
ShSerge, выше почитай.

Дай ссылку. Нифига не понял. Я этот топик уже читал. Для себя файл давно уже скачал.
.

хоть бы одну неправильную запятую бы подсказал бы
20 окт 18, 09:11    [21709671]     Ответить | Цитировать Сообщить модератору
 Re: книжки по Sqlite на русском языке..  [new]
tchingiz
Member

Откуда:
Сообщений: 33908
White Owl,
дан
20 окт 18, 09:33    [21709675]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4      [все]
Все форумы / SQLite Ответить