Представлен (http://www.mail-archive.com/sqlite-announce@sqlite.org/...) релиз SQLite 3.20.0 (http://sqlite.org/), легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg.
Основные изменения (https://sqlite.org/releaselog/3_20_0.html):- Изменён текст некоторых сообщений об ошибках;
- Изменено форматирование вывода имён столбцов при использовании функций sqlite3_column_name() и sqlite3_column_name16(), которое приведено в соответствие с оформлением вывода в PostgreSQL, MySQL и SQLServer (например, при применении подзапросов имена раньше в зависимости от запроса выводились иногда как table.column, а иногда как column, теперь всегда выводится только column);
- Среди нарушающих совместимость изменений также осуществлён переход внутренних API для подключения расширений на новый интерфейс передачи указателей (https://sqlite.org/bindptr.html);
- Добавлено расширение COMPLETION (https://sqlite.org/completion.html) с реализацией системы автодополнения ввода, срабатывающей по нажатию клавиши Tab;
- Добавлено расширение UNION (https://sqlite.org/unionvtab.html), предоставляющее поддержку сводных виртуальных таблиц, в которых несколько разных таблиц можно представить в виде одной большой объединённой таблицы;
- Добавлено расширение SQLITE_STMT (https://sqlite.org/stmt.html) с реализацией эпонимических (eponymous, таблицы имя которых совпадает с модулем") виртуальных таблиц с информацией о подготовленных выражениях (prepared statement), ассоциированных с соединением к БД;- Встроенные функции date и time теперь можно использоваться в составе условий CHECK, в выражениях при определении индексов и в составе выражений WHERE в частичных индексах;
- Добавлена PRAGMA-команда secure_delete=FAST, при указании которой включается режим быстрого безопасного удаления данных - в b-tree деревьях содержимое удаляемых элементов обнуляется, но может какое-то время оставаться в списках free-page;
- В интерфейс командной стоки (https://sqlite.org/cli.html) добавлена поддержка автодополнения ввода по нажатию клавиши Tab (можно использовать как readline, ак и linenoise), добавлена команда ".cd", в командах ".schema" и ".tables" обеспечена возможность отображения схем из всех прикреплённых БД, реализована опция "--newlines" для вывода командой ".dump" содержимого без экранирования символов перевода строки и возврата каретки;- Улучшена работа планировщика запросов:
- При генерации индивидуальных циклов для OR-выражений, не меняющиеся WHERE-блоки теперь вычисляются один раз вне цикла;
- Обеспечена проверка прикреплённых параметров для определения возможности задействования частичных индексов;
- При определении двух возможных планов выполнения запроса, для которых вычислен одинаковый вес, теперь выбирается тот, в котором не используется сортировка;
- При разборе выражений WHERE обработка подзапросов теперь выполняется в самом конце, в надежде, что сработает более простое условие и выполнение подзапроса не потребуется;
- Прекращено применение flattening-оптимизации для подзапросов, в случае использовании LEFT JOIN и чтении данных из виртуальной таблицы, с целью исключить создание автоматических индексов для результата, которые могут замедлить выполнение запроса;
- В утилите sqlite3_analyzer (https://sqlite.org/sqlanalyze.html) обеспечено отображение размера метаданных в страницах btree;- Внесена порция оптимизаций, который позволили примерно на 2% снизить (https://sqlite.org/cpu.html) нагрузку на CPU.
URL: http://www.mail-archive.com/sqlite-announce@sqlite.org/...
Новость: https://www.opennet.ru/opennews/art.shtml?num=46980
Лучше бы переписали на c++ и использовали встроенные в плюсы регулярки.
Ага. Из-за сомнительной радости юзать "встроенные" регулярки, переписывать прожект на плюсы - отличный план!
> Ага. Из-за сомнительной радости юзать "встроенные" регулярки, переписывать прожект на
> плюсы - отличный план!А что там переписывать, c++ с сями почти совместим. Немного модернизировать - и будет работать.
> Немного модернизировать - и будет работать.P.S. Сам так много раз делал.
>> Немного модернизировать - и будет работать.
> P.S. Сам так много раз делал.Им не надо "немного модернизировать — и будет работать", им это ещё поддерживать. Если ты много раз делал из проекта помойку, это не значит, что такое всех устроит.
больших помоек, чем проекты на сях, не найти.
> больших помоек, чем проекты на сях, не найти.npm, /windwos/system32/, cms-ы на php, ... Ну, дальше сам.
>npm
>Cвы серьёзно? 100% JavaScript
#>>>ольших помоек, чем проекты на сях, не найти.
>>npmЭто был пример бОльшей помойки, чем...
> вы серьёзно? 100% JavaScript
...чэм грузины, Вали-ико-о-о !
> больших помоек, чем проекты на сях, не найти.Сказал человек, который пользуется ОС, в которой не используется код на Си, в том числе в ядре. Или нет?
>> больших помоек, чем проекты на сях, не найти.
> Сказал человек, который пользуется ОС, в которой не используется код на Си,
> в том числе в ядре. Или нет?Используется, и это прискорбно.
> Используется, и это прискорбно.Так в чём проблема-то? Пересядь на написанную такими же продвинутыми, которые пишут операционки на Яве/Яваскрипте/Расте/Хаскеле, а через полгода отпишись тут, как оно, ощущаются ли преимущества языка, всем ли знакомым уже поставил, сколько серверов перевёл.
А то кричать "ОС на Расте была бы лучше, чем ОС на Сях" вы можете, а доказать свои слова - нет.
Немедленно сделай вдоль! :)
Это не "переписать на плюсах", это "добавить проблемы плюсов к пробемам си". Нормальный, рекомендуемый плюсовый стиль с C не имеет практически ничего общего.
> Нормальный, рекомендуемый плюсовый стиль с C не имеет практически ничего общего.кем рекомендуемый? Лично Бъёрном? Прям в спецификации так прописано : "это единственно верный и рекомендуемый стиль для программ на с++, остальные мы не рекомендуем использовать"? Если нет, то нафига эта демагогия?
Да, лично, с Саттером вместе. Вот тут: https://github.com/isocpp/CppCoreGuidelines/
Вы, наверное, рекомендованного стиля для JS/Java не видели... Реально мозг выносит, против тех же Сей (не ++) и прочих «привычных» языков.
А ссылку?
> Вы, наверное, рекомендованного стиля для JS/Java не видели... Реально мозг выносит, против
> тех же Сей (не ++) и прочих «привычных» языков.А ссылку? В свою очередь, вот современные практики С: https://news.ycombinator.com/item?id=9018247
вобще говоря не совсем так.
местами совсем не так.
что минусуете? pcre лишняя зависимость, поэтому в sqlite нет регулярок, приходится через питон определять функцию. А в стандартной библиотеке c++ регулярки есть. И вообще C без плюсов устарел, а код на нём в большинстве случаев жуткая фекалия из-за чрезмерного и неоправданного использования фанатиками препроцессора.
> pcre лишняя зависимостьА libstdc++ не лишняя, выходит? В чём разница?
"if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C" -- Linus Torvalds
Переведите пожалуйста подковырку, чтобы русский человек понял смысл подначки.
"Си хороши уж тем, что я в Крестах не очень" - примерно так.Насчет "переписать все на Крестах, чтобы регулярки были" - это просто-таки вершина мысли, почти эталонная. Конечно, если авторам SQLite вдруг захочется добавить встроенные регулярки, они никак не смогут это сделать без переписывания на Кресты, ага.
Вы и в английском не очень.
Как говорил один Чеширский Кот: "I'm not here, sir, to remedy your ignorance".
> Переведите пожалуйста подковырку, чтобы русский человек понял смысл подначки.Если [использование] си даст нам только возможность держать плюсанутых на расстоянии [от проекта], то это само по себе уже будет мощным аргументом в пользу [использования] си.
Перевод без контекста все равно бессмысленен.
Получается тупое хейтерство, а его тут, на самом деле, нет.Кресты, в основном, используются вместо С ради ООП. То есть - реализуем все сложности, заворачиваем их в классы поплотнее, высовываем наружу интерфейсы. Тому, кто придет следом, не нужно зарываться в сложности реализации, он работает с интерфейсами классов. Это прекрасно подходит для масштабных проектов высокого уровня - и ни к черту не годится для ядра. Потому что системные разработчики, искренне полагающие, что там, за интерфейсом, происходит какая-то магия, которую необязательно понимать - страшнее обезьян с гранатой. Порог вхождения в ядро должен обеспечивать, что дошедший досконально понимает, что именно он делает и почему. Вот именно это С, в отличие от Крестов, и обеспечивает ipso facto. А все прочие аспекты, по большому счету, вторичны.
Лично я больше всего хейтю си из-за того, что там нет шаблонных функций, constexpr, enum classов, вывода типов. А также из-за фанатизма фанатиков использовать препроцессор, который приводит к крайне трудноотлавливаемым ошибкам и неудобствам в отладке, потому что внезапно код в редакторе оказывается не кодом, который компилируется. Ведь если подумать, никто в плюсах не мешает писать код в сишном функциональном стиле. Но фанатиков не переубедить.
А в самом деле, почему не использовать вместо макросов inline-функции. Даже C их поддерживает.
> из-за фанатизма фанатиков использовать препроцессорНикакого фанатизма тут нет. Использование препроцессора было необходимо из-за отсутствия inline-функций, и сейчас ещё бывает необходимо из-за отсутствия шаблонов. Но все давно поняли, что это — зло, и пытаются его избегать.
Да, шаблоны — тоже зло, если их использовать к месту и не к месту, да ещё с большим уровнем вложенности.
>стараются избегать
>#define SQLITE_N_BTREE_META 10
>#define FTS2_HASH_BINARY 2
>#define sqliteHashFirst(H) ((H)->first)
> Ведь если подумать,то иногда лучше жевать чем думать
> никто в плюсах не мешает писать
> код в сишном функциональном стиле. Но фанатиков не переубедить.сишном функциональном
> сишном функциональномфункциональный - это в лисп. сишный стиль - процедурный.
> Лично я больше всего хейтю си из-за того, что там нет шаблонных функций,
> constexpr,если для функций, то насколько я понимаю
static inline int shit(int x) __attribute__ ((pure))
{
return x + x;
}будет иметь тот же эффект (и без кучи идиотских ограничений constexpr'a)
> enum classов
Это вот так FOO::BAR ? И чем оно лучше FOO_BAR ?
> Ведь если подумать, никто в плюсах не мешает писать код в сишном функциональном стиле. Но фанатиков не переубедить.
Ну да, и заниматься например вот такой идиотией:
p = (struct cpp_designers_are_fucking_idiots *)malloc(XXX);
> будет иметь тот же эффект (и без кучи идиотских ограничений constexpr'a)Во-первых, какие у constexpr есть идиотские ограничения в C++14, которых нет у pure-функции?
Во-вторых, использование __attribute__ ((pure)) резко делает ваш код не сишным. Это не С, а C as understood by gcc. [[pure]] обещали, кстати, в С++17, но не завезли, к сожалению.> Это вот так FOO::BAR ? И чем оно лучше FOO_BAR ?
Тем, что не приведётся автоматически к инту.
> p = (struct cpp_designers_are_fucking_idiots *)malloc(XXX);
Кто мешает конкретно тут написать new?
> Перевод без контекста все равно бессмысленен.Это да.
> Получается тупое хейтерство, а его тут, на самом деле, нет.Гм-хм ...
https://lwn.net/Articles/249460/
> Linus Torvalds <torvalds-AT-linux-foundation.org>
> C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
> I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.
> C++ leads to really really bad design choices.
Еще раз: Линус рассуждает о том, в чем варится сам. О системном программировании.
И, что характерно, он таки прав - в этой нише высокоуровневым и мультипарадигменным делать нечего, и те программисты, кто готов гнаться за их плюшками, мостят своими розовыми мечтами дорогу в ад.Цитирование этих суждений вне контекста разработки ядра и системных утилит - глупость или демагогия.
"Было бы величайшей ошибкой думать" (точная цитата из собрания сочинений Ленина).
Борясь с вырыванием цитаты из контекста, вы стали на сторону куда большего зла - приписывание другим своих мыслей. При этом вам привели полную цитату, без вырывания из контекста. Из Ленина вы взяли неполную. Зато приписали Линусу то, что он не говорил. На досуге узнайте, на чем написал Линус совсем не системный git.
На том, на чем умеет лучше всего, очевидно.
Да, возможно, я думаю о людях слишком хорошо.
Но согласитесь, то, что я действительно хочу их понять, а не просто развесить ярлыки, уже дорогого стоит ;)
> бессмыслененСпасибо хоть не бессмыслененен.
>Порог вхождения в ядро должен обеспечивать, что дошедший досконально понимает, что именно он делает и почему.Не преувеличивайте насчёт необходимости глубокого понимания, что там внутри ядра происходит. Аккуратно заполняете ядерные структуры указателями на свои функции и ... драйвер символьного усторойства (реального аппаратного) работает и прерывания обрабатываются. Проверено.
Рада синдрома утенка он используется.
#ifndef FOO_H_
#define FOO_H_struct foo;
struct foo *foo_create(int arg);
int foo_bar(struct foo *foo);
int foo_quux(struct foor *foo);
void *foo_destroy(struct foo *foo);#endif
А теперь покажи как зарыться в сложности реализации.
> не нужно зарываться в сложности реализацииЭто если доверять на 100% неведомо кому на другой стороне глобуса, который "реализовал все сложности, завернул их в классы поплотнее, высунул наружу интерфейсы". После одного-единственного натыкания на подводный камень это доверие улетучивается как сухой лёд на солнце.
Боги! Так никто же ничего не прячет. Хочешь покопаться - исходники-то доступны.
Но если вы разбираетесь с конкретной подсистемой в проекте масштаба OpenOffice, вы предпочтете, чтобы логика, не имеющая прямого отношения к этой конкретной подсистеме, максимально была из нее вынесена наружу и не путалась под ногами здесь и сейчас. Но при этом максимально же была собрана воедино, когда действительно понадобится. Да вдобавок - была понятна без изучения всего кода, который ей пользуется.Впрочем, предвижу холивар с рассказами, как все это (зачем-то) делается на Сях (почти не стоя в гамаке). Ага, делается, еще как. Давайте будем сразу считать, что я посрамлен, унижен, поставлен на место и больше не вызываю никакого интереса. Не будем увеличивать энтропию.
> предвижу холивар с рассказами, как все это (зачем-то) делается на Сях (почти не стоя в гамаке)Можно пару примеров стояния в гамаке? Чего именно в Си не хватает? Про шаблоны и исключения все всё уже поняли, пожалуйста, что-нибудь другое.
Вот есть, например, аналог класса на Си https://www.opennet.ru/openforum/vsluhforumID3/111926.html#58 . Это гамак или хороший пример?
ну как минимум с виртуальными функами это будет печаль, с наследованием - тоже непросто (деструктор статический). если и делать кресто-подобный стиль, то забивай структуру указателями на функи, например как там: https://github.com/ofiwg/libfabric
Наследование нужно чуть чаще чем никогда.
> Чего именно в Си не хватает?
> Про шаблоны и исключения все всё уже поняли, пожалуйста, что-нибудь другое.constexpr, move semantics, лямбды. Типобезопасность, в конце концов, когда можете в qsort передать свой компаратор, и компилятору будет чуть легче найти потенциальные проблемы, чем с void*, а заодно заинлайнить и заоптимизировать.
"Даже если бы C давал лишь отсутствие C++ разработчиков в проекте, одно лишь это было бы уже мощным аргументом в его пользу".Сложный/примитивный прекол (или я недалёкий надмозг).
> Переведите пожалуйста подковырку, чтобы русский человек понял смысл подначки.Линус ругает не таких, как он. Ничего особенного. Вот, и г-н Crazy Alex подтвердит.
Гуле-транслейт:
Если выбор C должен был делать * ничего *, но сохранить программистов на C ++, это само по себе было бы огромной причиной для использования Cоборот 'do nothing but keep out' оно не смогло, и 'keep' совсем мимо, там примерно так: "Одно только то, чтоб не допускать цпп-програмеров, было бы..."
Я-то подтверждаю, но при всём моём уважении к Линусу я его в непогрешимые боги не записывал и не собираюсь. И с его отношением к плюсам, как и к свободному софту ни хрена не согласен.
Продолжайте держать нас в курсе.
Л. Торвальдс гуру и авторитет в области ядра конкретно Linux. Вот в отношении ядра и будем считать его высказывания авторитетными.
>Л. Торвальдс гуру и авторитет в области ядра конкретно Linuxи в области VCS и конкретно Git. И в области управления крупными и очень крупными проектами.
Во всем остальном можешь считать себя более авторитетным... Хотя нет, еще нюанс, Линус школу давно закончил.
Только вот VCS цельнотянутая с Monotone и BitKeeper. Качество кода ядра вызывает много вопросов, помню свежеиспеченную libata, это тихий ужас. Проектом он управляет далеко и не только один. Но человек заслуженный, это бесспорнно.
> Только вот VCS цельнотянутая с Monotone и BitKeeper. Качество кода ядра вызывает
> много вопросов, помню свежеиспеченную libata, это тихий ужас. Проектом он управляет
> далеко и не только один. Но человек заслуженный, это бесспорнно.— вы прослушали пересказ Шукшина "Срезал" в исполнении жертвы ЕГЭ
>> pcre лишняя зависимость
> А libstdc++ не лишняя, выходит? В чём разница?в том, что стандартная библиотека, которая поставляется с компилятором и включается во все программы на языке. впрочим пофиг. Тому, что в sqlite нет встроенных регулярок - нет оправдания. Из-за этого мне приходится заморачиваться с питоном там, где можно было бы использовать консольный клиент.
> Тому, что в sqlite нет
> встроенных регулярок - нет оправдания. Из-за этого мне приходится заморачиваться с
> питоном там, где можно было бы использовать консольный клиент.Так не заморачивайся с питоном, возьми ту библиотеку регулярок, которая тебе нравится.
ага, предлагаешь заморочиться ещё больше и переписать консольный клиент. А потом заморочиться ещё больше, и переписать dbeaver.
> ага, предлагаешь заморочиться ещё больше и переписать консольный клиент.Ну возьми grep.
libstdc++ лишняя зависимость, поэтому в sqlite нет регулярок, можно через питон определять функцию. А в стандартной библиотеке C регулярок нет. И вообще C с плюсами устарел, а код на нём в большинстве случаев жуткая фекалия из-за чрезмерного и неоправданного использования фанатиками шаблонов и наследования.
Но есть Rust, он значительно новее их обоих ;)
Встраиваемую РСУБД на раст переписать забыли.
Вот поэтому на нём и не надо писать ничего настолько базового, как SQLite. Ещё лет пять, как минимум. Потому что ни хороших практик, ни списков известных граблей ещё толком нет, и формируются они далеко не быстро.
> Но есть Rust, он значительно новее их обоих ;)В части шаблонов и наследования, как и многого другого, он от крестов ничем не отличается.
> libstdc++ лишняя зависимость, поэтому в sqlite нет регулярок, можно через питон определять
> функцию. А в стандартной библиотеке C регулярок нет. И вообще C
> с плюсами устарел, а код на нём в большинстве случаев жуткая
> фекалия из-за чрезмерного и неоправданного использования фанатиками шаблонов и наследования.ну так не надо быть фанатиками. Где ты у меня увидел требование стать фанатиком? В си объетивно не хватает функций, но есть фанатики, которые упорно продолжают юзать костыли (препроцессор) там, где в плюсах есть встроенные типо- и кодобезопасные конструкции жля этого.
> есть фанатики,
> которые упорно продолжают юзать костыли (препроцессор) там, где в плюсах есть
> встроенные типо- и кодобезопасные конструкции жля этого.Можно конкретный пример?
>> есть фанатики,
>> которые упорно продолжают юзать костыли (препроцессор) там, где в плюсах есть
>> встроенные типо- и кодобезопасные конструкции жля этого.
> Можно конкретный пример?я уже наприводил конкретных примеров в обсуждении.
> В си объетивно не хватает функций,Напримep ?
>> В си объетивно не хватает функций,
> Напримep ?все возможности c++, которые можно использовать при программировании в стиле си.
Конкретнее пожалуйста.
>> а код на нём в большинстве случаев жуткая фекалия...Покажи свой код.
Ссылку на git в студию.
Теперь погугли про перфоманс регулярок в типичных реализациях stdlib
кому надо больше производительности - тот ещё раз переопределит функцию. Всё равно тормознутей, чем вызов питоней функцию через cffi уже не будет.
Тогда уж на Rust.
> Тогда уж на Rust.раст совместим с си? Не, я конечно за перевод на раст, но это никто делать не будет, ибо тяжело и никому не нужно.
>> Тогда уж на Rust.
> раст совместим с си? Не, я конечно за перевод на раст, но
> это никто делать не будет, ибо тяжело и никому не нужно.Да, совместим.
>>> Тогда уж на Rust.
>> раст совместим с си? Не, я конечно за перевод на раст, но
>> это никто делать не будет, ибо тяжело и никому не нужно.
> Да, совместим.То есть ты берёшь код на си, меняешь пару незначительных деталей и получаешь код на раст?
Нет. Получаеш код на Си. Код на Раст получится когда 100% кода будет переведено на Раст, а не несколько процентов, и будет проведён рефакторинг и чистка от unsafe кода. А до этого момента, особой разницы не будет, только синтакс другой.
значит не совместим (речь не о бинарной совместимости, а о совместимости исходников)
> То есть ты берёшь код на си, меняешь пару незначительных деталей и получаешь код на раст?Не. Ты берёшь corrode и он делает из C'шного проекта rust'овый.
>> То есть ты берёшь код на си, меняешь пару незначительных деталей и получаешь код на раст?
> Не. Ты берёшь corrode и он делает из C'шного проекта rust'овый.ага, волшебным образом сам реинжинирит код, чтобы можно было юзать почти без доработки. И borrow checker сам удовлетворяет. Расскажи эти сказки кому другому.
Нафик-нафик.
Все зачотные вещи написаны на си.
На крестах кодят всякий шлак клиентский и игры.
<dba-mode-on>За использование регулярок с SQL вообще убивать надо.</dba-mode-off>
Уважаемый Максим, а можно опцию "не показывать комментарии начинающиеся на "Лучше бы""? Я заметил что их авторы как правило не компетентны и не уважают проделанный труд других людей.
> Уважаемый Максим, а можно опцию "не показывать комментарии начинающиеся на "Лучше бы""?Тут без СУБД со встроенной поддержкой регулярок не обойтись...
Лучше бы переписали на разные языки чтобы в том же C#, например, просто работало, без матов, бубнов, получасовых гуглений и антинаучного тыка, независимо от битности ОС.
> Лучше бы переписали на разные языки чтобы в том же C#, например, просто работало, без матов, бубнов, получасовых гуглений и антинаучного тыка, независимо от битности ОС.Нет, не лучшее. Потому что вендузятник должен срадать.
А зачем вам в вашей прекрасной винде всякие левые поделия? Пользуйтесь официальным решением проверенного вендора - MS Access!
Зачем - чтобы работало и под Linux и под Mac (благо .Net - штука кроссплатформенная), а также потому, что Access (RIP) убог как и MS Access убога как и embedded варианты SQL Server. А под виндой я сижу, хотите верьте, хотите нет, но вот так, реально по одной единственной причине: под Linux нет Visual Studio - полноценной IDE для C# с рефакторингом ReSharper и визуальным дизайнером форм. Но аккурат сегодня зарелизили JetBrains Rider, так что может скоро настанет наконец вндкпц...
Иди в винду.
Также не поясните, что быстрее, WITHOUT ROWID и PRIMARY KEY из 2х целочисленных полей, или отображение этих дх полей в rowid и обратно (напр бинарным сдвигом и бинарным ИЛИ)? Если второе, то неплохо бы это иметь встроенным в саму базу.
> Также не поясните, что быстрее, WITHOUT ROWID и PRIMARY KEY из
> 2х целочисленных полей, или отображение этих дх полей в rowid
> и обратно (напр бинарным сдвигом и бинарным ИЛИ)?Так проверьте же. Прямо на своих задачах.
> Если второе, то неплохо бы это иметь встроенным в саму базу.
Patches are welcome, не?
> Так проверьте же. Прямо на своих задачах.конвертация таблицы в другой формат может несколько суток занять.
> конвертация таблицы в другой формат может несколько суток занять.Кто же заставил держать такую таблицу в sqlite?
>> Так проверьте же. Прямо на своих задачах.
> конвертация таблицы в другой формат может несколько суток занять.Так сделай тестовую поменьше.
несколько суток с момента этой новости - давно прошли. А ты все еще даже не попробовал. Ты их руками, по одному байтику конвертируешь, с 9 до 18?(и нет, не надо "делать поменьше", тебя, на самом деле, не интересует как оно работает на таблицах поменьше, тебя интересует как оно работает на _твоей_ таблице. Никто кроме тебя это проверять не будет. Если бы мне была нужна подобная оптимизация - я бы давно именно это и сделал. И еще одну с default rowid и отдельно - составным ключом, никогда не знаешь, что придет в голову сложным оптимизаторам)
https://www.sqlite.org/src/tree?ci=trunk
Код sqlite это все-таки хороший пример для обучения того как надо писать код. К слову, для меня, например, отлично, что они используют не монструозный git, а простой fossil (ими же и созданный). Современным хипстерам стоит поучиться подходу sqlite.
Скорее, это пример того, что команда хороших инженеров может работать на любой дряни, и того, что в промышленных решениях иногда дешевле поддерживать какую-то экзотику чем мигрировать на более распространённые и эффективные вещи.
Отлично, гит уже для хипстеров. Куда дальше дна скатываться комментаторам на опеннете?
> Отлично, гит уже для хипстеров. Куда дальше дна скатываться комментаторам на опеннете?Дна чего? Дно ближайшего пруда не сравнится с дном Марианской впадины. А та, в свою очередь, лишь мелкая морщинка на стыке тектонических плит ...
> Современным хипстерам
> стоит поучиться подходу sqlite.С каких это пор хипстерам потребовалось обучаться велосипедостроению?
>> Современным хипстерам
>> стоит поучиться подходу sqlite.
> С каких это пор хипстерам потребовалось обучаться велосипедостроению?leftpad же.
> К слову, для меня, например, отлично, что они используют не монструозный git,
> а простой fossil (ими же и созданный).Сколько там было переездов туда-сюда? Наш майнтейнер sqlite3 (и fossil, ага) уже ухахатываться устал, похоже.
Простой fossil несколько кривоват by design: линия коммитов по wall time --- для распределённой системы это супер-находка.
Поиск по UTF-8-строкам без учёта регистра до сих пор не работает из коробки? Помню, раньше было два варианта решения (костыля):
1) Перекомпилировать с ICU, увеличив объём либы на 10-15 метров и замедлив скорость поиска в 4 раза.
2) Внедрить грязный фикс для кириллицы прямо в if — если маленькая буква, то из кода символа вычитаем 32.
А вы чисто технически как это себе представляете ? Так чтобы без ICU и чтоб корректно работало ?
> А вы чисто технически как это себе представляете ? Так чтобы без
> ICU и чтоб корректно работало ?Элементарно сделать без ICU. Просто, для каждой локали (благо, их не так много) сделать свои upper(), lower() и т.д. Cделать, чтобы это были указатели на функции. Переключил локаль на русскую — upper() указывает на ru_upper(). Я уже пробовал так делать, но мне совершенно не хочется каждый раз при обновлении sqlite перекомпилировать всё это заново.
Судя по предлагаемому решению, ты не знаешь, что в локали ru_RU.UTF-8 можно использовать хоть иероглифы с эмоджами, не говоря уже про буквы всех европейских языков. Да и о количестве возможных локалей скорее всего тоже не в курсе и путаешь общее количество с количеством установленных на твоей машине.
> Судя по предлагаемому решению, ты не знаешь, что в локали ru_RU.UTF-8 можно
> использовать хоть иероглифы с эмоджами, не говоря уже про буквы всех
> европейских языков. Да и о количестве возможных локалей скорее всего тоже
> не в курсе и путаешь общее количество с количеством установленных на
> твоей машине.Я знаю. Только, наверное, если я спецом выбрал ru, то всяко, не для того, чтобы искать по арабской вязи. Количество локалей. Ну пусть будут не все существующие, а самые популярные. Вон, Firefox поддерживает почти сто локалей, и ничего, «не жужжит».
> Вон, Firefox поддерживает почти сто локалей, и ничего, «не жужжит».Бери с него пример (в последнем).
Теперь хотелось бы услышать отчего и почему авторы библиотеки должны лепить (и поддерживать) уродский костыль ради вашего юзкейса.
Мыши плакали, кололись, но не хотели внедрять KOI-8RU