Опубликован релиз SQLite 3.36, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55354
> Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциумнадо было на Rust переписать,тогда бы деньги потекли рекой
Это, конечно, было бы великолепно, но такой крупный проект наверняка само по себе было бы дорого переписывать
Нет, конечно, на раст невозможно не то что переписать, а даже написать такой проект как SQLite.
Припадки хейтеров Раста уже на конвульсии похожи
> Припадки хейтеров Раста уже на конвульсии похожиКак приятно когда есть на свете адекватные люди, скрывающие твои комментарии. Как всегда до безобразия глупые. Тем более что ты сам это понимаешь. Ты ведь ни один язык не осилил. Твоё тявканье про раст похоже на дёрганье беспомощьной амёбы
Гугл все оплатит.
>> Обеспечена генерация ошибки при попытках доступа к идентификатору строки (rowid) в представлении (VIEW) или подзапросе. Для возвращения возможности доступа к rowid для представлений предусмотрена сборочная опцмия "-DSQLITE_ALLOW_ROWID_IN_VIEW"А почему?
Перевод не очень удачный. У вьюх и поздапросов не может быть своих ROWIDов, поэтому обращаться к ним - плохая примета. Но, поскольку у корпорастов принято всё делать в трансанальном стиле, то для них оставили лазейку с опцией SQLITE_ALLOW_ROWID_IN_VIEW при включении которой они будут получать значение -1 (кажется).
ну в корпорастных как ты изволил выразиться базах вполне себе можно писать во вьюхи, что тут такого плохого. Если отношение не биективно, но тебе просто не даст писать
>>> У вьюх и поздапросов не может быть своих ROWIDовтоварищ, у вас гибернатор разморозился.
1) нет причин, по которым single table view не может иметь rowid
2) rtfm://"updatable join view"
> 1) нет причин, по которым single table view не может иметь rowidНет, запись в таблице может иметь rowid, и такое вполне себе работает в сабжевой версии:
create table test(i integer primary key, s text);
create view vtest as select rowid as 'rowid', i, s from test;
> 2) rtfm://"updatable join view"
The 'O' in "SQLite" stands for "Oracle". Вы, товарищ, многого ждёте от встраиваемой БД.
В SQLite вьюхи тупо не апдейтятся [1]. Но можно повесить триггер, который будет делать инсерт или апдейт соответствующей или вообще другой таблицы. Только вью не узнает что там в результате изменилось. Например продолжим издеваться над vtest созданным выше:create trigger TTestInsert instead of insert on vtest begin insert into test values (new.i, 'LOL!'); end;
create trigger TTestUpdate instead of update on vtest begin update test set i=new.i, s='BWOGHAGHA' where i=old.i and s=old.s; end;
insert into vtest(s) values('x') returning *;
<null> | <null> | xselect * from vtest;
22 |22 | LOL!update vtest set s='y' returning *;
<null> | 22 | yselect * from vtest;
22 | 22 | BWOGHAGHAВот как-то примерно так.
Список литературы:
Ну и до кучи проверил в постгресе пункт (1)
Если явно не включать в текст запроса во вьюхе oid - то и в Pg заселектить его из вьюхи не получится, ровно как в SQLite:create table test(i serial primary key, s text) with oids;
create view vtest as select * from test;insert into vtest(s) values ('a') returning *; -- works
insert into vtest(s) values ('b') returning oid,*; -- failing
insert into test(s) values ('c') returning oid,*; -- worksselect oid, ctid, i, s from test; -- works
select oid, i, s from vtest; -- failingВ Оракле проверять лень..
Используют для разработки, кстати, fossil, а не git
наверное потому что Рич написал fossil тоже
>>>потому что Рич написал fossilгосподи и он фидошник штоль?
Лишь бы не rust
Почему?
Rust его и многих других впопеннетчиц в детстве гнобил 🤣 Детские-с травмы, сэр!
Чувак, они tcl используют, настолько немодные. Хруст им не грозит еще лет сорок.
Хорошая СУБД
Все-таки, неплохая БД.
На днях ее как раз поминал, когда потребовалось вытащить часть файлов из бэкапа яблочно устройства.. а там они - в каталогах с именами с 00 по ff, вместо имен файлов - хеши и без каких-либо расширений. Притом, все вперемешку от фоток и заметок и до смс'ок, контактов, закладок и приложений. Сопоставления между именами в резервной копии, реальным именем, адресом и к чему относится - в многомегабайтной БД.Слава б.-гу, что, если где и попадаются встраиваемые бд, то это скорее всего "оно" и его запросто можно расковырять весьма обширным инструментарием, а то и скрипты какие-нибудь набросать по быстрому.
Чем оно лучше firebird?
чем firebird ))
Удобвством интеграции в проект. Никаких пакетов и зависимостей. Один файл с исходным кодом на C и заголовочный, и sqlite используется в программе.
Чем Dqlite не угодил?
какой-то неведомый труп студента
Я снова упёрся рогом в отсутствие явных секвенсов =/На запрос в гугле `sqlite sequence` всплывает статья на сайте разработчика SQLite, где автор др*чит на автоинкременты.
Причём печаль в том, что автоинкремент фактически реализует функционал секвенса. В SQLite есть всё, чтобы реализовать явные секвенсы. Но их нет.
У тебя в языке нет мьютекса или переменных?
Ты странный. sqlite не предназначен для параллельной модификации данных. Поэтому и генераторы уникальных последовательностей не нужны.
> Ты странный. sqlite не предназначен для параллельной модификации данных. Поэтому и генераторы
> уникальных последовательностей не нужны.сгенерируйте мне уникальную последовательность для НЕ первичного ключа? Например, для связи many-to-many?
Embarcadero сделала InterBase 2020, в том числе для Android. Зачем что-то ещё?
дед, ты опять таблетки выпить забыл?
проприетарный какашок.а сабж давно под ведройдом работает...