Представлен (http://permalink.gmane.org/gmane.comp.db.sqlite.announce/36) релиз SQLite 3.8.6 (http://sqlite.org/releaselog/3_8_6.html), легковесной базы данных, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Nokia, Bentle и Bloomberg.В новом выпуске:
- Добавлена возможность (http://www.sqlite.org/lang_expr.html#hexint) использования в запросах шестнадцатеричных чисел (формат 0x1234);
- Увеличена производительность оператора "IN", что позволило до пяти раз ускорить выполнение некоторых запросов;
- Внесённые оптимизации позволили на 25% снизить общую нагрузку на CPU по сравнению с выпуском 3.8.0, при тестировании в valgrind и test/speedtest1.c. При этом размер исполняемого файла увеличился по сравнению с выпуском 3.8.0 на 5%;
- Устранена появившаяся в выпуске 3.8.2 ошибка в реализации "CREATE INDEX", которая при определённых обстоятельствах (http://www.sqlite.org/src/info/9a6daf340df99ba93c) могла привести к созданию UNIQUE-индекса для столбцов, содержащих повторяющиеся данные.
- В команду "PRAGMA integrity_check (http://www.sqlite.org/pragma.html#pragma_integrity_check)" добавлен код для выявления проблем с уникальностью в индексах UNIQUE и нарушений условия NOT NULL;
- Добавлена SQL-функция likely (http://www.sqlite.org/lang_corefunc.html#likely);- Лимит SQLITE_MAX_ATTACHED (http://www.sqlite.org/limits.html#max_attached) увеличен с 62 до 125.
URL: http://permalink.gmane.org/gmane.comp.db.sqlite.announce/36
Новость: http://www.opennet.me/opennews/art.shtml?num=40393
> Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Nokia, Bentle и Bloomberg.Мне кажется, любая из этих компаний в одиночку могла оплатить всей команде разработчиков SQLite безбедную жизнь на протяжении нескольких поколений и при этом самой не обеднеть сколько-нибудь заметно.
Ан нет - аж консорциум собрали, отдуваются.
Ну справедливости ради надо отметить, что многие компании входят во множество различных "консорциумов" и поддерживают множество различных проектов. И пусть "консорциум" чем то, что Оракл сделал с MySQL. Так что пусть лучше всё остаётся так, как есть.
ТО чо вы тут написали - похожая бред, гугл перевёл? промт.
И пусть "консорциум" -> И лучше "консорциум"Настолько плохо знаешь язык, что любая опечатка делает текст непонятным? Бывает, вот только плохое знание языка это повод сидеть молча и "не отсвечивать" по языковым вопросам.
Всё решила запятая, которой нет.
А strict-mode так и запилили? Последний раз когда пробовал SQLite было возможно записать в любое поле любой тип данных, независимо от того, какой тип этму полю был декларирован
> А strict-mode так и запилили? Последний раз когда пробовал SQLite было возможно
> записать в любое поле любой тип данных, независимо от того, какой
> тип этму полю был декларированНу так там и данные все в одном виде хранятся - в текстовом. Считайте это "фишкой", всё-таки сфера применения у SQLite немного специфичная...
>> Ну так там и данные все в одном виде хранятся - в текстовом.Хранение данных - это уже несколько иной слой представления, к SQL отношения не имеющий.
>> всё-таки сфера применения у SQLite немного специфичная...
Сфера применения у SQLite обширнейшая. Часто это динамические языки. Где и так всё на расслабоне. И строгость в отношении хотя бы к хранилищу данных была бы очень к месту.
>>>> всё-таки сфера применения у SQLite немного специфичная...
>>Сфера применения у SQLite обширнейшая. Часто это динамические языки. Где и так всё на расслабоне. И строгость в отношении хотя бы к хранилищу данных была бы очень к месту.С кривыми руками выбирай другую ДБ. Хотя кривые руки обычно от кривых мозгов
От кривых рук никто не застрахован - человеческий фактор. Если я запишу строку в поле объявленное как числовое - значит скорее всего я допустил ошибку. Компьютер должен предотвращать потенциальные человеческие ошибки, а не поощрять. Лучше уж комптютер пусть проверяет чем мне по пол часа вручную отлавливать баг.
Так и заставьте компьютер проверять попытку записи букв в поля для этого не предназначенные.Все проверки на клиенте-до записи в БД
> А strict-mode так и запилили? Последний раз когда пробовал SQLite было возможно
> записать в любое поле любой тип данных, независимо от того, какой
> тип этму полю был декларированВсе типы представлены для совместимости с другими БД и имеющимися схемами.
Внутри sqlite тип один.
Не вижу причин цитировать здесь документацию sqlite. У mysql так вообще 8 разных движков хранения данных. Пусть хоть в json хранит - какая разница. Важно что отсутствуют проверки типов при чтении/pfgbcb. Что в сильно усложняет поиск ошибок при разработке.
Вообще-то sqlite - позиционируется именно как простейшая и легковесная БД, где многие вещи, типичные для "больших" БД просто выкинуты для обеспечения этих простоты и легковесности.
Если вам нужны такие проверки, возможно вам стоит смотреть на более "продвинутые" БД - postgresql/mysql/mariadb/etc...
>> как простейшая и легковесная БД, где многие вещи, типичные для "больших" БД просто выкинуты для обеспечения этих простоты и легковесностиНу прям определение всех новоиспеченный nosql key-value помоек. Значит и sqlite можно причислить к ним же
Ник у тебя подходящий для такого комментария.
А чем не nosql-помойка. Куда угодно записывай что угодно. Оно проглотит и даже ворнингом не поперхнется
Когда все собеседники намекают на кривые руки, это повод задуматься, Дубират! ))
>> ДубиратСобеседники со второго сообщения начали на личности переходить. Словно я не sqlite критикую, а их мамку.
Проблема мною озвученная имеет место быть. В сети масса вопросов и возмущений по этой теме. Достаточно погуглить sqlite strict affinity.
Кстати, на одном форуме говорится, что раньше strict affinity был. Потом автор его выпилил с формулировкой "ненужно"
>Внутри sqlite тип один.Вообще-то нет. Для примера "The INTEGER storage class, for example, includes 6 different integer datatypes of different lengths. This makes a difference on disk."
Другое дело, что тип связан с самим значением(ячейкой), а не с полем(колонкой, столбцом).
А мне наоборот эта особенность sqlite очень нравится.Если отсутствие типа не влияет на скорость работы и потребляемое место, то к черту эти тупые ограничения. Работать в этом плане с sqlite после традиционных sql одно удовольствие.
likely разве не было?
интересно когда они починят upper для не английских букв
кодировка? не, не слышал.
в том то всё и дело что поддержка ASCII символов без кириллицы,
но я вообще использую UTF-8, а проблему пока решаю добавлением в таблицу такого же поля со значением в upper-е
Для безграмотных сообщаю, кириллица(да и вообще все символы выше первых 128 в однобайтных кодировках) не входит в ASCII. Так что выражение "ASCII символов без кириллицы" само по себе глупость.Размер таблиц преобразований для всевозможных encoding и их collations больше размера самого sqlite, было бы глупо их включать. При этом sqlite позволяет добавлять и использовать в запросах пользовательские функции, так что ничто не мешает добавить свою версию преобразования. Хотя с такими знаниями ты вряд ли это осилишь.
> Для безграмотных сообщаю, кириллица(да и вообще все символы выше первых 128 в
> однобайтных кодировках) не входит в ASCII. Так что выражение "ASCII символов
> без кириллицы" само по себе глупость.ну извини, запятую забыл… "ASCII символов, без кириллицы"
сразу доказывать, что самый умный стал - молодец!
> Размер таблиц преобразований для всевозможных encoding и их collations больше размера самого
> sqlite, было бы глупо их включать.конечно, глупее некуда …
>При этом sqlite позволяет добавлять
> и использовать в запросах пользовательские функции, так что ничто не мешает
> добавить свою версию преобразования.конечно ни кто не мешает, но писать udf как-то не хочется, тем более под андроид
> Хотя с такими знаниями ты вряд ли это осилишь.тут ты возможно прав, знания нужно усилить…
> Для безграмотных сообщаю, кириллица(да и вообще все символы выше первых 128 в
> однобайтных кодировках) не входит в ASCII. Так что выражение "ASCII символов
> без кириллицы" само по себе глупость.
> Размер таблиц преобразований для всевозможных encoding и их collations больше размера самого
> sqlite, было бы глупо их включать. При этом sqlite позволяет добавлять
> и использовать в запросах пользовательские функции, так что ничто не мешает
> добавить свою версию преобразования. Хотя с такими знаниями ты вряд ли
> это осилишь.Они в стандартной библиотеке...
действительно все решается через стандартную icu
http://www.sqlite.org/faq.html#q18
1. собери с icuили
2. через внешнюю функцию