RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 
Visa 
4274 3200 2453 6495 

Small. Fast. Reliable.
Choose any three.

Изменения SQLite от версии 3.5.9 до 3.6.0

SQLite version 3.6.0 (2008-07-16) содержит много изменений. Как обычно с проектом SQLite, большинство изменений полностью обратно совместимы. Однако, несколько изменений в версии 3.6.0 несовместимы и могли бы потребовать модификаций кода приложения и/или make-файлам. Этот документ краткий обзор изменений в SQLite 3.6.0 с особым вниманием к несовместимым изменениям.

Ключевые пункты:
  • Формат файла базы данных неизменен.
  • Все несовместимости находятся во внутренних интерфейсах и следовательно должны оказать нулевое влияние на большинство приложений.

1.0. Несовместимые изменения

Несовместимые изменения покрыты сначала, так как они являются самыми важными.

1.1. Обзор несовместимых изменений

  1. Изменения объекта sqlite3_vfs.

    1. Сигнатура метода xAccess изменена, чтобы возвратить код ошибки и сохранить его в целое число, на которое указывает параметр, вместо того, чтобы возвратить непосредственно. Это изменение позволяет xAccess() сообщать о неудачах. В сотрудничестве с этим изменением новый расширенный код ошибки был добавлен SQLITE_IOERR_ACCESS.

    2. Метод xGetTempname был удален из sqlite3_vfs. Метод xOpen расширен, чтобы открыть временный файл, когда параметр имени файла NULL.

    3. Добавлен метод xGetLastError() в sqlite3_vfs для возвращения определенных для файловой системы сообщений об ошибках и кодов ошибок назад к SQLite.

  2. Сигнатура xCheckReservedLock в sqlite3_io_methods была изменена так, чтобы это возвратило код ошибки и сохранило его булев результат в целое число, на которое указывает параметр. В сотрудничестве с этим изменением был добавлен новый расширенный код ошибки SQLITE_IOERR_CHECKRESERVEDLOCK.

  3. Когда SQLite перенесен к новым операционным системам (операционные системы кроме Unix, Windows и OS/2, для которых порты обеспечиваются вместе с ядром), две новые функции, sqlite3_os_init() и sqlite3_os_end(), должны быть обеспечены как часть порта.

  4. Путь, которым операторы IN и NOT IN обрабатывают NULL в их правых выражениях, был приведен в соответствие стандарту SQL и другим системам базы данных SQL.

  5. Имена столбцов для наборов результатов SELECT исправили в некоторых случаях, чтобы работать как другие базы данных SQL.

  6. Изменения вариантов времени компиляции:

    1. SQLITE_MUTEX_APPDEF больше не признается. Как замена, альтернативная реализация mutex может быть создана во времени выполнения, используя sqlite3_config() с оператором SQLITE_CONFIG_MUTEX и объектом sqlite3_mutex_methods.

    2. Опции времени компиляции OS_UNIX, OS_WIN, OS_OS2, OS_OTHER и TEMP_STORE были переименованы, чтобы включать префикс "SQLITE_", чтобы помочь избежать конфликтов пространства имен с прикладным программным обеспечением. Новые названия этих вариантов соответственно: SQLITE_OS_UNIX, SQLITE_OS_WIN, SQLITE_OS_OS2, SQLITE_OS_OTHER и SQLITE_TEMP_STORE.

1.2. Изменения слоя VFS

SQLite version 3.5.0 добавил новый слой интерфейса OS, который обеспечил абстракцию основной операционной системы. Это было важными инновациями и было полезно в переносе и поддержании SQLite. Однако, разработчики обнаружили некоторые незначительные недостатки в оригинальном дизайне "виртуальной файловой системы", введенном в версии 3.5.0 и таким образом, SQLite 3.6.0 включает некоторые небольшие несовместимые изменения.

Ключевой пункт: несовместимые изменения в интерфейсе операционной системы SQLite для версии 3.6.0 затрагивают только редкие ситуации, которые используют интерфейс виртуальной файловой системы, определенную приложением реализацию mutex или используют другие неясные варианты времени компиляции. Изменения, введенные версией 3.6.0 SQLite, окажут нулевое влияние на подавляющее большинство приложений SQLite, которые используют встроенные интерфейсы для Unix, Windows и OS/2 с использованием стандартной конфигурации сборки.

1.3. Изменения в обращении IN с NULL

Все версии SQLite до и включая версию 3.5.9 не справились с NULL на правой стороне операторов IN и NOT IN. Определенно, SQLite ранее проигнорировал NULL на правой стороне IN и NOT IN.

Предположим, что нам определили таблицу X1 следующим образом:

CREATE TABLE x1(x INTEGER);
INSERT INTO x1 VALUES(1);
INSERT INTO x1 VALUES(2);
INSERT INTO x1 VALUES(NULL);

Учитывая определение X1 выше, следующие выражения исторически оценили к FALSE в SQLite, хотя правильный ответ на самом деле NULL:

3 IN (1,2,NULL)
3 IN (SELECT * FROM x1)

Точно так же следующие выражения исторически оценили к TRUE, когда на самом деле NULL также правильный ответ здесь:

3 NOT IN (1,2,NULL)
3 NOT IN (SELECT * FROM x1)

Историческое поведение SQLite неправильно, согласно стандарту SQL:1999, и это несовместимо с поведением MySQL и PostgreSQL. Версия 3.6.0 изменяет поведение IN и NOT IN , чтобы соответствовать стандарту и дать те же самые результаты как другие СУБД SQL.

Ключевой пункт: изменение способа, которым NULL обрабатывается в IN и NOT IN, является технически исправлением ошибки, не конструктивным изменением. Однако, разработчики должны проверить, чтобы гарантировать, чтобы приложения не зависели от более старого поведения до модернизации до версии 3.6.0.

1.4. Изменения правил именования колонки

Имена столбцов, о которых сообщают подзапросы соединения, были изменены немного, чтобы работать больше как другие ядра базы данных. Рассмотрите следующий запрос:

CREATE TABLE t1(a);
CREATE TABLE t2(x);
SELECT * FROM (SELECT t1.a FROM t1 JOIN t2 ORDER BY t2.x LIMIT 1) ORDER BY 1;

В версии 3.5.9 запрос выше возвратил бы отдельный столбец, названный "t1.a". В версии 3.6.0 имя столбца просто "a".

SQLite никогда не делал обещаний о названиях колонок в наборе результатов SELECT, если колонка не содержит пункт AS. Таким образом, это изменение имени столбца технически не несовместимость. SQLite просто изменяется от одного неопределенного поведения до другого. Тем не менее, много запросов зависят от неуказанной колонки, называющей поведение SQLite и таким образом, это изменение обсуждено под несовместимым подзаголовком изменений.

1.5. Изменения вариантов времени компиляции

Вариантами времени компиляции к SQLite управляет макрос C-препроцессора. Версия 3.6.0 SQLite изменяет названия некоторых из макросов так, чтобы все макросы C-препроцессора, которые являются определенными для SQLite, начинались с префикса "SQLITE_". Это сделано, чтобы снизить риск столкновений имени с другими программными модулями.

Ключевой пункт: у изменений вариантов времени компиляции есть потенциал, чтобы затронуть make-файлы в проектах, которые делают сборки под заказчика SQLite. Эти изменения должны оказать нулевое влияние на код приложения и для большинства проектов, которые используют стандартную сборку SQLite.

2.0. Полностью обратно совместимые улучшения

В дополнение к несовместимым упомянутым выше изменениям версия 3.6.0 SQLite добавляет следующие совместимые изменения и улучшения:

  1. Новый интерфейс sqlite3_config() позволяет настроить поведение SQLite во времени выполнения. Настройки с использованием sqlite3_config() включают следующее:

    1. Определите альтернативу mutex внедрение, используя SQLITE_CONFIG_MUTEX с объектом sqlite3_mutex_methods.

    2. Определите альтернативу malloc через SQLITE_CONFIG_MALLOC с объектом sqlite3_mem_methods.

    3. Частично или полностью отключите использование mutexes, используя SQLITE_CONFIG_SINGLETHREAD, SQLITE_CONFIG_MULTITHREAD и SQLITE_CONFIG_SERIALIZED.

  2. Новый параметр SQLITE_OPEN_NOMUTEX сделан доступным для sqlite3_open_v2().

  3. Новый параметр sqlite3_status() позволяет запросить исполнительный статус SQLite во времени выполнения.

  4. sqlite3_memory_used() и sqlite3_memory_highwater() устарели. Эквивалентная функциональность теперь доступна через sqlite3_status().

  5. sqlite3_initialize() можно вызвать, чтобы явно инициализировать подсистему SQLite. sqlite3_initialize() вызывают автоматически, вызывая определенные интерфейсы, таким образом, использование sqlite3_initialize() не требуется, но это рекомендуется.

  6. sqlite3_shutdown() заставляет SQLite выпускать любые системные ресурсы (выделения памяти, mutexes, открытые дескрипторы файлов), которые, возможно, были ассигнованы sqlite3_initialize().

  7. sqlite3_next_stmt() позволяет обнаружить все подготовленные запросы , связанные с соединением с базой данных .

  8. Добавлена page_count PRAGMA для возвращения размера основного файла базы данных в страницах.

  9. Добавлено новое расширение R*Tree index.