The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз СУБД SQLite 3.31 с поддержкой генерируемых столбцов

23.01.2020 10:26

Опубликован релиз SQLite 3.31.0, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg.

Основные изменения:

  • Добавлена поддержка генерируемых столбцов (вычисляемых столбцов), позволяющих при создании таблицы определить столбец, значение которого автоматически вычисляется на основе содержимого другого столбца. Генерируемые столбцы могут быть как виртуальными (формируемыми на лету при каждом обращении), так и сохраняемыми в БД (сохраняются при каждом обновлении связанных столбцов). Содержимое генерируемых столбцов доступно только в режиме чтения (изменение производится только через модификацию значения в другом столбце, задействованном при вычислении). Например:
    
       CREATE TABLE t1(
          a INTEGER PRIMARY KEY,
          b INT,
          c TEXT,
          d INT GENERATED ALWAYS AS (a*abs(b)) VIRTUAL,
          e TEXT GENERATED ALWAYS AS (substr(c,b,b+1)) STORED
       );
    
  • Добавлены PRAGMA trusted_schema, настройка SQLITE_DBCONFIG_TRUSTED_SCHEMA и сборочная опция "-DSQLITE_TRUSTED_SCHEMA", позволяющие управлять включением защиты от атак через модификацию схемы данных в БД. При активной защите ограничивается использование SQL-функций (не помеченных как SQLITE_INNOCUOUS) в триггерах, представлениях, выражениях CHECK и DEFAULT, индексах и генерируемых столбцах. Также отключается использование виртуальных таблиц в триггерах и представлениях, если виртуальная таблица явно не объявлена с флагом SQLITE_VTAB_INNOCUOUS.
  • Реализована возможность присвоения определённым в приложениях SQL-функциям свойств SQLITE_INNOCUOUS (безобидные функции, которые не зависят от внешних параметров и не могут использоваться для совершения вредоносных действий) и SQLITE_DIRECTONLY (только прямой вызов в SQL-запросах, без возможности применения в триггерах, представлениях и схемах структуры данных);
  • Добавлен модуль uuid с реализацией функций для обработки UUID ( RFC-4122);
  • Добавлена PRAGMA hard_heap_limit и функция sqlite3_hard_heap_limit64() для управления максимальным размером кучи;
  • В PRAGMA function_list добавлен вывод типа, свойств и числа аргументов каждой функции;
  • В виртуальную таблицу DBSTAT добавлен режим агрегирования данных;
  • В sqlite3_open_v2() реализована опция SQLITE_OPEN_NOFOLLOW, позволяющая запретить открытие символических ссылок;
  • Для аргумента PATH, передаваемого в JSON-функции, добавлена поддержка нотации массивов "#-N";
  • В системе распределения памяти lookaside реализована поддержка двух отдельных пулов памяти, каждый из которых может использоваться для выделения блоков разного размера (разделение позволяет расширить применение системы lookaside, при этом снизив размер выделяемого на каждое соединение буфера со 120 до 48 КБ);
  • Прекращена поддержка PRAGMA legacy_file_format, которая была несовместима с VACUUM, генерируемыми столбцами и убывающими индексами (поддержку устаревшего формата можно вернуть через флаг SQLITE_DBCONFIG_LEGACY_FILE_FORMAT в sqlite3_db_config()).


  1. Главная ссылка к новости (https://www.sqlite.org/release...)
  2. OpenNews: Уязвимость в SQLite, позволяющая удалённо атаковать Chrome через WebSQL
  3. OpenNews: Релиз СУБД SQLite 3.30
  4. OpenNews: Доступен Dqlite 1.0, распределённый вариант SQLite от компании Canonical
  5. OpenNews: Представлена новая техника эксплуатации уязвимостей в SQLite
  6. OpenNews: Удалённо эксплуатируемая уязвимость в SQLite, затрагивающая браузеры на базе Chromium
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52238-database
Ключевые слова: database, sqlite
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (54) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:31, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Добавлена поддержка генерируемых столбцов (вычисляемых столбцов), позволяющих при создании таблицы создать столбец, значение которого автоматически вычисляется на основе содержимого другого столбца.

    Знатоки, объясните: чем представления (view) хуже? Или я не понял и это вообще про другое?

     
     
  • 2.4, Аноним (4), 11:42, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Основное отличие в том, что эту штуку можно не вычислять каждый раз, записав её на диск. А с view так нельзя. Ну ещё все данные и их производные в одной таблице, не нужно писать в одну и читать из другой как это будет с view.
     
     
  • 3.10, Аноним (1), 12:32, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, теперь стало более понятно.
     
  • 3.12, Аноним (12), 12:56, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >эту штуку можно не вычислять каждый раз, записав её на диск

    А от VIRTUAL тогда чем?

     
     
  • 4.14, Аноним (14), 13:00, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тем, что не надо каждый раз выражение писать в select. Или делать отдельный view.
     
     
  • 5.33, ананим.orig (?), 23:32, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    главное чтобы по нему можно было индекс строить
     
  • 3.13, Аноним (14), 12:59, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Основное отличие в том, что эту штуку можно не вычислять каждый раз, записав её на диск. А с view так нельзя.

    В "больших" СУБД есть materialized view, тоже можно не вычислять каждый раз. Надеюсь, сабжевая фича является частью плана по их включению в SQLite.

     
     
  • 4.27, Q2W (?), 18:01, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Таким темпами он станет SQHeavy
     
     
  • 5.29, Аноним (14), 18:50, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Black Progressive Industrial Heavy SQL.
    То, что надо!
     
  • 2.22, Аноним (22), 13:23, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    VIEW, например, в постгресе - кошмарная и вредная конструкция, не дающая менять схему нижележащих таблиц, а для MATERIALIZED либо требующая блокировки, либо создающая кучу других проблем (в случае REFRESH CONCURRENTLY). Всё что угодно лучше этой гадости - функции, триггеры, обычные таблицы обновляемые запросом, CTE, в зависимости от того что применимо. Почему бы также и не вычисляемые столбцы, хотя по мне так их сфера применения тоже очень сильно ограничена (в основном обратной совместимостью).
     
     
  • 3.30, Аноним (30), 21:01, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С MV и в оракле тяжко, если много данных и обновление таблиц частое.
     
  • 3.50, KonstantinB (??), 19:50, 25/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чаще всего виртуальные столбцы используются для того, чтобы построить индекс по выражению.
    В постгресе это можно делать и напрямую
     

  • 1.2, Аноним (2), 11:36, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Наверное прикольно. Но когда включат поддержку icu? что бы запрос Select "Ы" like "ы" выдавал 1?
    известный баг\фича))
     
     
  • 2.5, Аноним (5), 12:04, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Раз не включают по умолчанию значит это никому не нужно. А полтора землекопа могут и сами себе с ICU собрать.
     
  • 2.7, пох. (?), 12:07, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если он начнет такое выдавать - да, это будет именно баг, поэтому ответ - никогда.

    А поддержка upper/lower - существует, но, поскольку это embedded db, collate function ты ей должен предоставить сам - https://sqlite.org/c3ref/create_collation.html - можешь себе "включить поддержку icu", если умеешь.

    Для "неумеющих кодить" существует postgres.

     
     
  • 3.20, Аноним (14), 13:15, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Для "неумеющих кодить" существует postgres.

    Домино — это вам не шахматы, тут думать надо.

     
  • 2.15, Аномномномнимус (?), 13:00, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Поддержка включена если собрать правильно
     
     
  • 3.26, Аноним (26), 17:57, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    это не та поддержка, которую хочет аноним (если мы правильно понимаем его пример - он, вероятно, хотел все же не безусловно и во всех случаях чтобы Ы было like ы, а работающий collation ?)

    Это поддержка в cli, без которой предложенную им строку вообще набрать, скорее всего, не получится.

     
  • 2.36, Аноним (36), 02:08, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Никогда, в SQL like --- _регистрозависимый_.

    Для поиска независимо от регистра используют UPPER/LOWER или бывает делают ilike, но ilike нет в стандарте SQL, это расширение на усмотрение авторов СУБД.

     

  • 1.3, PavloT (?), 11:42, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Просто удобство. Не всегда хочется создавать отдельную сущность в виде view. В принципе можно и запросом разрулить.
     
     
  • 2.6, Аноним (5), 12:05, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Имхо творят сущностный для видимости деятельности. Ничем хорошим это обычно не заканчивается.
     
     
  • 3.16, Аноним (14), 13:01, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Полагаю, в этом случае закончится поддержкой materialized views, что неплохо.
     

  • 1.8, Аноним (8), 12:14, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    SQLite - хороший, годный продукт. Но кажется легковесность потихоньку улетучивается.
     
     
  • 2.9, пох. (?), 12:27, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    embedded db не обязана быть "легковесной", ей надо быть - embeddable.

    А дальше, в случае sqlite все зависит от тебя - часть фич включается только по запросу, часть можно отключить. Но для этого его надо пересобирать, причем в некоторых случаях - из исходников.
    Нет, sqlite-autoconf-3310000.tar.gz - это не исходник, и конфигурируется там не всё.

     
     
  • 3.40, Аноним (40), 12:28, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    lite тоже не значит легковесный?
     
  • 2.41, Аноним (40), 12:29, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    lite тоже не значит легковесный?
     
  • 2.44, Alexey (??), 21:50, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    По объему он все еще очень легкий
     

  • 1.11, ыы (?), 12:55, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    бизнес-логика встраиваемая прямо в таблицы... каша будет...
     
     
  • 2.17, Аноним (14), 13:02, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Устраивать или нет кашу — выбор разработчика.
     
     
  • 3.18, ыы (?), 13:04, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, есть такие любители - выдать толпе мыло, веревку и посмотреть что получится в итоге...
    а получится как в расте (недавно), получится как в вордпрессе (перманентно)
     
     
  • 4.19, Аноним (14), 13:13, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В расте получился способ ускорить работу, отключая всякие проверки. В результате можно догнать по производительности такие языки, как C и C++.

    > получится как в вордпрессе (перманентно)

    Если вас беспокоит безопасность — не пользуйтесь вордпрессом.

     
     
  • 5.21, ыы (?), 13:16, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У вас на все есть ответ :)

    а как потом выгружить такие столбцы для переноса в другую базу? mysql например?

     
     
  • 6.23, Аноним (22), 13:29, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Также как из MySQL выгружать в PostgreSQL, а из оного - в Oracle, а оттуда в Redis. т.е. со всей логикой ровно никак - это разные базы с разными фичами, не прозрачно взаимозаменяемы и не должны такими быть. А если только данные, то брать и выгружать, и вычисляемые столбцы в этом только помогают, потому что помогают обеспечить совместимость и прозрачную конвертацию схемы. Собственно, никакую другую сложную бизнес логику в них и не запихнуть.
     
  • 6.25, Аноним (14), 16:50, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У вас на все есть ответ :)

    Нас, анонимов, много. Хоть кто-нибудь, да ответит.

    > а как потом выгружить такие столбцы для переноса в другую базу? mysql например?

    Почему бы вам не спросить, как переносить из MySQL в SQLite пользователей и их права доступа, например?

     

  • 1.24, Аноним (24), 16:46, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Подскажите, что там с внедрением столбцов с типом DATETIME, DATE, TIME? Хочу искать по индексу по таким полям.

    Не понял, что с UUID можно ли делать PK поле с UUID? Можно ли его генрить автоматический и получать на INSERT?

    Будет ли когда нибудь обратный индекс для текста?

     
     
  • 2.28, Q2W (?), 18:06, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А чем integer не устраивает в плане индексирования?
     
     
  • 3.42, Аноним (24), 16:48, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Тем, что нужно делать [mYear, mMonth, mDay, mHour, mMinute, mSecond] по шесть полей на одну дату (и то если повезло и они в UTC), а если дат несколько, то это просто какой-то кошмар их создавать.

    В целом конечно можно и с UnixTime немного погеммороиться, но было б удобнее.

     
     
  • 4.46, Q2W (?), 11:42, 25/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    С unixtime, имхо, будет достаточно удобно, если для преобразования даты/времени в unixtime и обратно юзать какую-нибудь либу.

    В остальном - это же sqLITE. Преимущество должно быть в т.ч. в простоте.

     
     
  • 5.48, MBG (?), 17:59, 25/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем? Еесть нативная поддержка, зачем юзать какую-то либу? Только чтобы не читать документацию?:)
     
     
  • 6.51, Q2W (?), 22:31, 25/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нет нативной поддержки, об том и тред.
     
     
  • 7.52, MBG (?), 08:51, 26/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Понял, «чукча не читатель, чукча писатель», в документацию религия не позволяет. Итак, смотрим https://www.sqlite.org/lang_datefunc.html

    Compute the date and time given a unix timestamp 1092941466.
    SELECT datetime(1092941466, 'unixepoch');
    Compute the date and time given a unix timestamp 1092941466, and compensate for your local timezone.
    SELECT datetime(1092941466, 'unixepoch', 'localtime');
    Compute the current unix timestamp.
    SELECT strftime('%s','now');
    the date and time given a unix timestamp 1092941466.
    SELECT datetime(1092941466, 'unixepoch');
    Compute the date and time given a unix timestamp 1092941466, and compensate for your local timezone.
    SELECT datetime(1092941466, 'unixepoch', 'localtime');
    Compute the current unix timestamp.
    SELECT strftime('%s','now');

    И так далее, еще много всего.

    Сразу добавлю, что функции эти существуют давно и надо было только документацию открыть.

     
     
  • 8.53, пох. (?), 10:27, 27/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    это все же не тип данных DATE или DATETIME, это преобразования впрочем, теперь ... текст свёрнут, показать
     
  • 2.31, Аноним (31), 21:13, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Подскажите, что там с внедрением столбцов с типом DATETIME, DATE, TIME? Хочу искать по индексу по таким полям.

    Не будет. Есть integer. Если нужно искать только по времени, и времена уникальны, то кодируешь в число и засовываешь в integer primary key, будет сверхбыстрый поиск, ибо integer primary key идёт в rowid.

    Если нужно искать по нескольким primary, то прикидываешь сколько бит нужно на каждый primary нужно и кодируешь всё в один rowid с помощью битовых операций. Поиск будет нормальный, нужно просто правильно запрос синтезировать. Единственный недостаток - слишком много надо ручками делать. Давно бы запилил то что нужно, но там PR принципиально не принимают, а значит любой вклад в эту базу - это зря потраченный труд и время.

     
     
  • 3.32, пох. (?), 21:33, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    индекс-то создать по стольким полям, сколько нужно, и не лезть в rowid - коран не велит?

    Обязательно заниматься неведомой херней?

    Правильно они такие PR не принимают - эта проблема в голове у оверинжинирнутого разработчика, а не в софте, который вполне последовательно реализует sql, а не костыли.

     
     
  • 4.35, Аноним (31), 01:31, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >индекс-то создать по стольким полям, сколько нужно, и не лезть в rowid - коран не велит?

    любые индексы будут медленнее rowida. Их ещё добавлять и удалять надо, ибо со включёнными индексам вставки будут очень медленные. rowid же используется самой базой и связан с низкоуровневым представлением на HDD, поэтому последовательный доступ и поиск при кодировании в rowid будет быстрым.

    Если у вас база в ведроприложении на несколько мегабайт, то вам пофиг. Если у вас многогоговая база на жёстких дисках, то вам не пофиг, будут импортироваться в неё данные неделю или 2 недели и будет 1 запрос идти минуту или 20 минут.

     
     
  • 5.38, пох. (?), 10:49, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    если у вас "многогиговая база на жестких дисках" не может работать банально с индексами потому что "вставки очень медленные", и вы вынуждены заниматься наколеночной "оптимизацией" с ручным складыванием битиков - вы что-то уже понапроектировали явно не то. Может вам вообще не нужен был sql (вручную битики перекладывать - вообще не то, для чего его задумали)?

    Возможно, именно sqlite для этого применения не очень подходил, хотя видел я немногогиговые (5-8 это ведь немного?) базы аж с FTS и весьма интенсивным добавлением данных в realtime - и ничего, жили.

    А в многогиговой базе на орацле у нас по 20 минут выполняется только всякая аналитика, где запрос на четыре экрана мелким шрифтиком - да и то если кэш не прогрет. И никто там вручную rowid не собирает по битикам, что странно. Ну, правда, стоило это довольно дорого.

     
  • 3.45, MBG (?), 07:52, 25/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну-ну, ври, да не завирайся (с) Если обосновать полезность и реализуемость фичи - сделают. Да, код напишут сами по лицензионным соображениям. В свое время я предложил добавить компрессию для расширения FTS - показал результаты тестов с компрессией и без, прислал свою реализацию для проверки. В итоге идею приняли и компрессию добавили. Так что если вы измеряете результат полезностью - все отлично, если же вам попиариться принятым в апстрим кодом - тогда вон в кде шлите, там имхо вообще все принимают (в качестве подтверждения можете нагуглить мою давнюю переписку с разработчиками akonadi).
     
     
  • 4.47, Аноним (31), 13:00, 25/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    у них mailing list без TLS. отказываюсь таким пользоваться.
     
     
  • 5.49, MBG (?), 18:02, 25/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Или крестик сними ими или трусы одень (с) нет проблем написать напрямую на почту DRH - не припомню случая, чтобы он мне не ответил. Ах да, попиариться не выйдет :)
     

  • 1.34, Ivan_83 (ok), 23:43, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лучше бы сборочную систему поправили, а то даже pread() и прочие фишки детектить не умеет, зато код их юзать умеет, если ручками задать дефайны при сборке.
    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241385
     
     
  • 2.37, Аноним (37), 08:21, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Тоже думаю что def это не простые фаилы если вы сможете собрать именно с этими дефами https://github.com/Griggorii/wine_d3d_def_source ваин то вот и напишите мне на почту гмаил ком ник тот же.
    Считаю что есть такие инструменты программирования которые ты считаешь мусором потому что просто не знаешь как применять.
     
  • 2.39, пох. (?), 10:55, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше бы сборочную систему поправили

    она ж целиком вторична и делается на от..сь.

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

    P.S. соберешься править - сделай еще параметры для WAL и синхронной записи при нем - а то и их приходится вручную определять. Причем bsdшный мэйкфайл такому тоже не обучен.

    P.P.S. мне лень, у меня и так все работает, да.

     

  • 1.43, Аноним (24), 16:50, 24/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А для meson как подпроект кто-то уже сделал версию для встраивания?
     
  • 1.54, iZEN (ok), 14:56, 27/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Этот релиз SQlite3-3.31.0 приводит к ошибке сегментации Thunderbird и Firefox - пришлось откатываться на предыдущую версию и восстанавливать профили пользователя.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру