Привет Всем!

На общее внимание и обсуждение выносится концепция undo/redo persistent transactions в ООБД Cerebrum . Возможно кто то найдет в ней дырки или возможность к усовершенствованию. Это поможет мне сделать свою ООБД более эффективной и полезной.

Важной особенностью СООБЗ Cerebrum является отличие в реализации транзакций по сравнению с общепринятой реализацией в базах данных. Система поддерживает многоуровневые undo/redo persistent однопользовательские транзакции. Undo/redo persistent transactions позволяют организовать общепринятую в пользовательском интерфейсе функциональность undo/redo на уровне ядра БД. Это помогает реализовать на основе ядра Cerebrum приложения CAD/CAM активно взаимодействующие с пользователем и требующие функциональность undo/redo.

Транзакции могут быть двух видов: с версионированием объектов и без версионирования объектов. Транзакции могут находиться в грязном и чистом состоянии. При создании новой транзакции с версионированием объектов предыдущее состояние всех объектов сохраняется в хранилище и создаются новые версии измененных объектов. При выполнении операции undo актуализируются предыдущие сохраненные версии объектов, а новые изменения становятся невидимыми. При выполнении операции redo происходит обратный процесс – измененные версии объектов вновь становятся видимыми. При многократном выполнении операций undo/redo производится актуализация версий объектов соответствующих транзакции выбранной операциями undo/redo.
В случае создания транзакции без версионирования объектов, новые версии объектов не создаются, изменения накапливаются в версиях ближайшей предыдущей транзакции с версионированием, а текущей транзакции присваивается статус «чистая». В случае завершения чистой транзакции по CommitTransaction транзакция остается в чистом состоянии, счетчик TransactionCount уменьшается на 1. В случае завершения чистой транзакции без версионирования по RollbackTransaction предыдущая транзакция переходит в грязное состояние, счетчик TransactionCount уменьшается на 1. В случае завершения грязной транзакции без версионирования по RollbackTransaction предыдущая транзакция переходит в грязное состоянии, счетчик TransactionCount уменьшается на 1. Завершение грязной транзакции по CommitTransaction либо создание новой следующей транзакции недопускается. В случае завершения грязной транзакции с версионированием все изменения объектов, накопленные в пределах данной версии откатываются. Если в процессе выполнения операции undo/redo актуализируется транзакция без версионирования то актуализируются версии объектов ближайшей к предыдущей транзакции с версионированием.

Для того чтобы посмотреть как это работает можно сделать следующее:
1. Скачать ООБД Cerebrum http://www.shuklin.com/download.aspx?file=ru_cerebrum_sdk
2. Развернуть архив и запустить файл Binary\Application\Debug\Cerebrum.DesktopClient.exe
3. Выбрать из меню File\Streams-01 пункт New Stream …
4. Подтвердить параметры создаваемой БД нажатием кнопки OK
5. Ввести имя файла создаваемой БД и подтвердить его создание нажав Save
6. Начать транзакцию нажав Begin
7. Заполнить БД тестовыми данными нажав Populate Images
8. Убедиться, что последнее созданное изображение имеет номер 099. Для этого перейти в конец списка и выделить последний элемент. Под списком отображается количество элементов в списке, общее количество транзакций / номер текущей активной тарнзакции.
9. Начать транзакцию нажав Begin
10. Заполнить БД тестовыми данными нажав Populate Images
11. Убедиться, что последнее созданное изображение имеет номер 199. Для этого перейти в конец списка и выделить последний элемент.
12. Повторить пункты 6. и 7. еще 5 раз. В результате в списке должно быть создано 8 транзакций и 700 элементов.
13. Убедиться, что последнее созданное изображение имеет номер 699. Для этого перейти в конец списка и выделить последний элемент.
14. Выполнить команду UNDO нажав на кнопку со стрелкой влево ‘<’
15. Убедиться, что последнее созданное изображение имеет номер 599 и текущая транзакция имеет номер 7.
16. Выполнить команду UNDO нажав на кнопку со стрелкой влево ‘<’
17. Убедиться, что последнее созданное изображение имеет номер 499 и текущая транзакция имеет номер 6.
18. Выполнить команду REDO нажав на кнопку со стрелкой вправо ‘>’
19. Убедиться, что последнее созданное изображение имеет номер 599 и текущая транзакция имеет номер 7.
20. Закрыть БД
21. Закрыть оболочку
22. Заново запустить файл Binary\Application\Debug\Cerebrum.DesktopClient.exe
23. Выбрать из меню File\Streams-01 пункт Open Stream …
24. Найти файл ранее созданной БД и подтвердить его открытие нажав Open
25. Убедиться, что последнее созданное изображение имеет номер 599 и текущая транзакция имеет номер 7.
26. Выполнить команду REDO нажав на кнопку со стрелкой вправо ‘>’
27. Убедиться, что последнее созданное изображение имеет номер 699 и текущая транзакция имеет номер 8.
28. Откатить все созданные транзакции выполнив 7 раз команду Rollback
29. В процессе отката убедится в последовательном уменьшении общего количества транзакций и элементов в списке.
30. Закрыть БД
31. Закрыть оболочку


С уважением,
Шуклин Дмитрий

MegabrainНачиная с "В случае создания транзакции без версионирования объектов, новые версии объектов не создаются, изменения накапливаются в версиях ближайшей предыдущей транзакции с версионированием.." мне непонятна ваша
.. хмм концепция. Что значит "изменения накапливаются в версиях ближайшей предыдущей транзакции с версионированием"? Какие такие изменения? А если предыдущей транзакции с версионированием нету? Тады где они накапливаются и накапливаются ли вообще? Какая транзакция у вас чистая, какая грязная. Дайте определение.

Привет.

Ща попробую объяснить.

Есть два режима функционирования ядра. С версионированием и без версионирования. Задается при создании БД. После создания БД изменить этот режим невозможно. Режим без версионирования работает быстрее но в нем не работает почти все обсуждаемое в данной теме - поэтому будем рассматривать только режим с версионированием.

В БД всегда существует хотябы одна транзакция. В ней накапливаются original версии объектов. Это те данные которые закомичены окончательно и бесповоротно. Эту транзакцию нельзя ни откатить ни откоммитить. Хотя при попытке выполнить операцию коммит для этой транзакции ничего плохого не произойдет. Коммит проведет флуш объектов. Эту транзакцию можно считать транзакцией с версионированием, так как она содержит оригинальную версию объектов. Если никаких транзакций больше в системе нет то все изменения объектов будут накапливаться в ней.

При создании первой пользовательской транзакции (фактически это уже будет вторая транзакция) она создается с версионированием всегда. Независимо от того просили мы ее с версионированием или нет. Таким образом всегда имеется предыдущая транзакция с версионированием (даже две). Если после создания этой транзакции были изменения объектов - то они попадают в proposed версию.

Эти две транзакции имеют несколько особое положение в системе и имеют для удобства обозначения original & proposed.

При старте следующей транзакции мы имеем свободу выбора. Запустить ее с версионированием или без. Без версионирования это будет похоже на транзакции MS-SQL когда бегинов может быть сколько угодно, а реальный роллбак только один. Чтобы сохранить соответвсие N бегинов - N rollbacks or commits я не рубаю в таком режиме все по первому же роллбак. Если допустим третьей и четрвертой пошли транзакции без версионирования то они получили статус чистых. После роллбака четвертой, третья получит статус грязной. Так как третья и четвертая без версионирования, то ближайшая предыдущая транзакция с версионированием - вторая. Именно в ней и будут накоплены все изменения. При ролбаке четвертой третья станет грязной. Закомитить ее будет невозможно (ибо валидация - хотя технически можно было бы но зачем?). При ролбаке третьей грязной станет вторая. При ролбаке второй - так как она с версионированием, будут удалены все версии объектов, которые в нее входят. Первая останется чистой. Измененные объекты прийдут к своему начальному состоянию.

Допустим мы не ролбачили ни третью ни четвертую а создали 5ю с версионированием. Тогда текущие изменения объектов будут накапливаться в 5й. и undo/redo пробегая по 1, 2 и 5й будут менять состояние всех аффектед объектов. При проходе 3й и 4й undo/redo будут оставлять активными изменения ближайшей предыдущей к ним транзакции с версионированием - тоесть 2й. Далее если стартовать 6ю без версионирования - то она будет по отношению к 5й так же как и 3я по отношению ко 2й.

bas Понравилась идея применния вашей СООБЗ для CAD/CAM/т.п. Если действительно можно будет реализовать концепцию модификации одного чертежа/сбоки несколькими пользователями одновременно, то просто супер. В этом одна из больших светлых целей. Спасибо. В принципе по типу file-sever (aka MS-Access) накрутить многопользовательский доступ вполне реально координально не меняя текущего ядра. Еще можно сделать single - thread service и попробовать реализовать client-server на основе .NET Remoting. Но client - server на single-thread OODB - несколько примитивно. В планах кое что по вкуснее.

MegabrainИ еще не вижу где их можно использовать. Объясните если не трудно. Текущую версию можно использовать как библиотеку классов обеспечивающую продвинутую сериализацию пользовательских объектов в файл в деск-топ приложении. Тоесть это "конкурент" structured storage от MS. На основе такой библиотеки можно сделать формат файла для приложения по типу Excel / Visio. например активная семантическая сеть очень похожа на чертеж Visio с формулами от Excel в узлах. Транзакции undo|redo позволят не парится с собственной реализацией версионирования изменений. Для формата файла документа, который должен хранить много сериализованных .NET объектов и если требуется предоставить пользователю функциональность undo/redo при изменении документа

MegabrainЯ понял о чем вы говорите. А такой вопрос. Допустим завершили мы успешно транзакцию, а потом выясняем что нафиг этого делать было не надо, а транзакция x-надцатая подтвержденная. И вдруг выясняется, она неправильная и надо вернуться к x-yнадцатой. Что делать в этом случае?
для конкретики. все транзакции с версионированием.
имеем 1, 2, 3, 4, 5

Допустим мы закомитили 5ю. тогда все ее изменения залились на 4й уровень. Осалось
1, 2, 3, (4+5)

Закомитили 4ю, потом 3ю получили

1, (2 + 3 + 4 + 5)

вот тут как раз точка последнего принятия решения. Или коммит - тогда все proposed изменения станут original и тогда уже хана - ничего не откатить, или наоборот сделаем rollback и вся работа будет уничтожена.

Если надо то можно начать еще одну - дочернюю после того как было закомичено или заролбачено несколько на том же уровне. В чемто это похоже на дерево транзакций, но в каждый конкретный момент времени существует только цепочка из транзакций. Можно всегда определить предыдущую или следующую.

undo/redo ходит по этой цепочке.

MegabrainВ вашей системе восстановление невозможно (как я понял). Ну после того как окончательный коммит проведен - ролбак невозможен. тут полная аналогия с обычными системами.

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

Petro123 bas
вы не участвовали в религиозных войнах про ООСУБД? ТОГДА МЫ ИДЁМ К ВАМ :))

ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ? (1,2,3,4,5,6,7,8,все) [new] Alexey Rovdo
http://www.sql.ru/forum/actualthread.aspx?tid=146255&pg=1&hl=%ee%ee%f1%f3%e1%e4+rovdo
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

может вас это и удивит, а может и нет, но толпа не определяет ничего. из того что толпа не в состоянии получить выгоду из ООБД не значит, что на этих БД некоторые индивидуумы не в состоянии заработать и главное решать задачи промышленного уровня.

MegabrainДля shuklin.
Нууу однопользовательский undo/redo не очень интересно обсуждать, Полностью согласен, но это уже сделано и свободно доступно. Если удовлетворит ограничением некоторой задачи - можно даже использовать.
Megabrainхотябы потому что в конечном итоге вы будете делать undo/redo многопользовательский.Ну а это только в планах. Увы в течении 5 минут такое не делается. Хороший многопользовательский режим потребует в первую очередь мултитреад ядра. Вот майлстоуны которые я примерно наметил

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

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

- жить станет лучше жить станет веселей )) тоесть полная реализация толстого клиент-сервер с активным сервером.

Petro123вы уж определитесь, какие у вас задачи:
- промышленного уровня? Тогда ближе к конкретике и примерам на практике
- теоретическая физика? Тогда форум надо другой (там где СУБД проектируют/операционки/нейронные_компьютеры)
У меня - эти обе задачи одновременно. Тоесть теоретическая физика применимая в реальной промышленности. При этом теоретическая физика как предмет более интересный на данном этапе более приоритетнее.

Petro1232. Если Вашу (с) СУБД используют в промышленности, не боитесь что Вас "поставят на бабки" за недочёты в проектировании/тестировании/реалзации/маркетинге/сопровождении/администрировании/масштабируемости/........Не боюсь. Во первых есть такая штука как лайценз агримент и дисклосуре. Нажал аццепт - пользуйся. Не нажал - не пользуйся. Во вторых какую только @#$%^ не эксплуатируют. По сравнению со многим @#$% которое я имел несчастье лечить от багов моя БД пример образцовой стабильности и надежности ))) Но это уже на самом деле грустно. Т.к. моя бд на данном этапе только в бете.

Petro123ну дык и привели бы пример стандартной реляционной системы "А" с такими_то проблемами, которые решила ваша система "Б".
Наверное это самое мое любимое и главное, именно отсюда часть ног выросла: http://www.microsoft.ru/offext/details.aspx?id=620

Petro123Это что? Проще? Экономичнее? Рентабильнее?
Ага но в OODB это все дело реализуется на порядки элегантнее и эффективнее. В том числе благодаря синонимии/омонимии объектных идентификаторов, описанной в соседнем топике.

Petro123ну и где тут проблема в стандартном исполнении студента "А" вашей задачи?Трудно не заметить, но всеже возможно - это БД на MS Access. Никакой объектности. Именно это и есть "А"

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

Petro123 Мы строим ООБД/Мы строим БД/Мы строим ЯДРО ООБД
Построение ООБД находится на одном из этапов построения ЯДРА ООБД.

Petro123Общее IMHO мнение - недорос ещё их уровень до конкуренции с РСУБД.Увы да. Одна из причин - жесткая идентификация экземпляров объектов уникальными ИД. Это тут же ставит крест на возможности полноценных JOIN. Если от этого отказаться и ввести свободную идентификацию - сетевые ООБД по эффективности модели данных тут же опережают РБД. Пока этого нет - отстают. На сколько мне известно все существующие промышленные ООБД придерживаются принципа идентификации объектов по ODMG - каждому объекту свой уникальный идентификатор. И как следствие не могут реализовать объектные VIEW (представить некоторую объектную структуру в виде производной объектной структуры). Как следствие в при длительной эксплуатации и изменении схемы данных приходится полностью переписывать все существующие приложения. Введение концепции синонимии/омонимии объектных идентификаторов позволяет решать эту проблему сетевых ООБД.