Yo.!

opendsa
Строки воссоздаются из оригинальной строки путем локального отката значений конкретной строки с текущего времени , до состояния на точку консистентности.
тогда для чтения каждой строки нуна перелопатить весь лог транзакций, имено поэтому в оракле разделены REDO и UNDO логи. слабо представляю в какой задачи будет оправдано использование версионности opendsa.


Нет , теоретически это должно занять ровно столько же времени как и индексный поиск по любой другой таблице, + чуть чуть нагрузки на CPU.
Тесты на производительность еще рано делать.
Соответственно рано говорить о производительности ( с чем то сравнивать).

Yo.!

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

Если это alter table то думаю что проблем не будет,
Изменение структуры ( записей таблиц системного каталога)
также регистрируется в логическом журнале.
просто операция займет еще чуть больше CPU.

Если удаление- создание , то это уже другая таблица , хоть и с тем же именем.

Изначатьно Версионность вводилась только для читающих транзкций , для любителей
получать консистентные репорты.
Для изменяющих транзакций есть другие уровни изолированности.
Я не вижу смысла изменять значение хоть и консистентным ,
но не актуальным на момент изменения значением.
Это не сервер отчетов , это в первую очередь OLTP сервер.

Поэтому и select ..... for update ведет себя именно так как описано в первом сообщении.
И по другому вести себя не будет никогда.
Это соответствует моему пониманию логической целостности всех данных сервера
на любой момент времени.

ОКТОГЕНopendsa, ещё вопрос.
А что будет с версиями при длительных транзакциях?
Как будет реагировать система на висячие транзакции?


Также как в оракле ORA-15555 или в информиксе диннная транзакция.
Откат начинается принудительно. По исключению не ловится.

Разработчик плагина может конечно перехватить исключение, но целостность данных сервера в 99.9 % будет нарушена.

Yo.!


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

Именно над этим вопросом я работую последние ~3 месяца.
Некоторые Таблицы системного каталога имеют псевдоверсионность
глубиной в 255 изменений, Каждая строка имеет ссылку на свою текущую версию.
Думаю все будет ОК , придет время , и если хватит у меня мотивации - вы все увидите.

Если поля не конвертируемы , то понятное дело будет откат,
потому как невозможно произветси преобразование к значениям требующимся в выборке.
Но сначала нужно этот функионал( изменение типов полей) в alter table реализовать.
Его там еще нет.

vadiminfoopendsa
Думаю все будет ОК , придет время , и если хватит у меня мотивации - вы все увидите.

Что мы можем такого увидеть? Самопальную РСУБД? Ить мы давно уже насмотрелись на много разных, в том числе и лидирующих СУБД.
Если у вас стока энгергии чтобы на такие сложные продукты замахиваться, то может луче найти другие цели? Поновее и поперспективнее? Ить сегодняшние лидеры в производстьве СУБД именно так и начинали, када идеи РСУБД еще тока появлялись.
Тут был парень с Селебрумом. Он пытался свое детище и СУБЗ назвать, и СУБД но с егойной новой МД. Т.е. чувствоал шо новое нуно, где нет еще развитых продуктов. Но само "новое" не проканалывало как новое, и тем более стоящее новое (у него это было скорее старое но с ошибкИми, и потому казалось новым для него). Но все же. А Вы просто РСУБД без всяких там попыток инноваций.

Все начиналось когда IBM купил infromix, я до сих пор люблю эту СУБД.
Потом я перескочил на Oracle. Охренел от его понимания целостности данных
в терминах его консистентности.

Что их этого получится - время покажет.
Пока это только гимнастика для мозгов и я никуда не спешу.

Хотелось бы что бы проект мне обеспечил мне безбедную старость, но до старости еще далеко.

NextManDimitry Sibiryakov
opendsa
Некоторые Таблицы системного каталога имеют псевдоверсионность глубиной
в 255 изменений, Каждая строка имеет ссылку на свою текущую версию.

Что-то мне это до боли напоминает...



Дайте ссылку плс

vadiminfo

Так и я о том же. Есть риски, что проект не подходит для обеспечения безбедной старости, поскоку от РСУБД уже почти все взяли для обспечения безбедной страсти другие, кто начинал 30 лет назад. Не говоря о том, что есть риски появления чего-то нового, что отменит все подобные проеты в принципе: чисто по времени.

Одни тратят свое свободное время на тюнинг машин который никогда не окупится,
а я время реализацию собственной СУБД.

Это мое хобби.

Это офтопик,
по существу есть что спросить - сказать ?

ОКТОГЕНopendsa,в любом случае, пороха вы скорее всего не изобретёте. Я бы посоветовал поразбираться с ораклом и сделать что-то подобное, но
легче в использовании.
Внутренности движка эти ребята вылизали до блеска, а вот лёгкость хромает,
и вряд ли когда будет приведено в норму(слишком дофига понаписано).
Это мои субъективные ощущения, но если они доведут до ума юзабельность,
то многим конкурентам придётся идти пить пиво.

Точно как у Oracle , уже не получится , у меня с ними разное виденние
точки консистентности для версионных транзакций
и при сложившейся
архитектуре моя консистентность проще в реализации.

Мне кажется что моя проще и для понимания рядовым программистом.

А в остальном попробую.

ЗЫ Спасибо за поддержку.

Gluk (Kazan)opendsaApexавторЕще одна отличительная особенность СУБД , что в таблицах , кроме системного каталога
не хранится null значения полей.
Отличительная от чего?

От всех других моторов СУБД где NULL поля занимают место в строках при хранинии записей на диске.

Неуд. Oracle не хранит NULL-значения в конце строки

Та мне побарабану, кто где хранит или не хранит.

У меня не хранит нигде кроме системного каталога.

ОКТОГЕНopendsa, а не надо делать "как у них", вы просто оттуда хорошие идеи возьмите, какие сможете.
Кстати, ограничение на 255 изменений это, ИМХО, не плюс. Это лишняя головная боль пользователям такой СУБД, ежели, к примеру, накладываются патчи на боевую базу, и тут раз - облом. Останавливать сервак, перезаливать дамп? Очень плохо.


Нут ту все предусмотрено ( в планах пока), если есть доступ к старым версиям строк
или при сборе статистики на таблицу ( с СВО конь еще не валялся) , то они полностью переконвертятся в последнюю версию. Если конечно значения ковертабельны.

Если при alter table перескочит значение 255 , то операция повиснет пока все старые версии
не конвертнет.
Там могут быть проблемы с длинными транзакциями, но я над этим еще думаю.

2 Gluk (Kazan) Правильнее сказать хранит, но место не занимает, хранит в битмапе строки
1 бит на одно поле.

Gluk (Kazan)

пабарабану, так и не треплись, об чем не знаешь

Та я про оракл в этом контексте ни слова не сказал.

Я говорил про Informix.

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

Я никому ничего не навязываю.

Еще раз спасибо за правильные вопросы.