Append only база данных. И как такой пользоваться?

Korni3 - append only

База данных создаваемая/управляемая утилитой korni3 является базой в которую можно только добавлять записи. Нет операция изменения записи и нет удаления. Вы можете только добавлять записи.

Как же идентифицировать обекты?

записи хранятся в таблицах (они создаются автоматически по первому требованию, если не существовали ранее) . у каждой записи ОБЯЗАТЕЛЬНО ДОЛЖНО быть поле id .

Но система korni3 автоматически создает поле временной метки zT timestamp и поле zU - пользователь как публичный ключ, + внутри файлов на диске в записи есть zS (цифровая подпись текущего юзера). Первичным ключем язвляется пара (id, zT)

При вставке записи система не пикнет и вставит еще одну запись c другой меткой времени, поэтому вы можете иметь несколько записей с одним и тем же id и разным zT - это необходимо учитывать при программировании.

Вам придется писать более сложные sql запросы, но ничего - потренируйтесь.

Как удалять ?

Вставьте метку, что запись удалена, или вставьте новую пустую версию записи. Ваше приложение может уметь это определять.

Прошлые версии могут быть удалены с диска, но не факт, что они не удалены в других файловых копиях этого хранилища.

Как изжать гонки состояний?

Чтобы избежать гонки состояний следуйте правилу “менять только свои записи”. т.е. если крайняя , известная вам запись (в вашей копии базы) изменялась юзером А , то только А и может её менять и ему решать что с ней делать. Если запись ваша - меняйте её.

С Большинством объектов, используемых в информационных системах, соц сетях, или бизнес системах легко следовать этому правилу безо всяких последствий т.к. там этоочевидно, например, что менять ваше объявление можете только вы…

Если нужно - сделайте таблицу “предложения изменений на объект типа Объявление”

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

Есть объекты которые предназначены для совместной работы, например параграфы совместно редактируемых документов в “гугл документах”. С такими объектами хочется иметь что то вроде CAS или транзаций. как быть ?

Вам позже может стать известно что данные которые только что меняли до вас, но без связи с вами, менялись кем то еще и там zT будет меньше и ваши изменения вступают с этим в конфликт… (дело даже не в том, чья версия будет в итоге)

Korni3 - AP система и в ней нет транзаций такого рода, как хочется ACID.

Поэтому Вам придется писать код, который будет при отображении информации учитывать несколько версий таких объектов и даже целые ветви изменений (как в git), чтобы в памяти соединять их и … иногда наверное придется показать пользователю диалог, что объект надо как-то смержить вручную. такие диалоги в таких системах придется предусмотреть.

Ещё, на крайний случай, пользователи могут повторно сделать действия, которые не прошли… бороться за свою “версию параграфа”. (впрочем, этот вариант доступен всегда)

Ещё в таких случаях полезно представить изменения, как цепочку идемпотентных операций, с “было/стало”, которые хранятся тоже в таблицах, чтобы ваше приложение могло легче обрабатывать такие ситуации.

Вам точно следует показывать пользователю в каком то журнале что, когда и как он изменил, чтобы он всегда мог найти свои данные, чтобы они для него не “терялись”. (в korni3 ничего не теряется - есть полная ретроспектива внутри, но её надо подержать и в интерфейсе)

что делать если я хочу сделать свои цифровые деньги и мне нужно сделать “двойную запись”

Перестаньте мыслить в категориях транзаций - начните мыслить в логике “публикаций документов”.

Один агент публикует документ, второй потвержает, что его прочитал другим документом… перепишите ваш алгоритм в таком роде. Если получается - на системе korni3 это реализуемо.

Я Хочу транзакционно менять значения, по несколько штук, чтобы никаких конфликтов не было. хочу! !! как быть ?

Есть такой метод “SWARM транзакции”. у вас есть значения (с их версиями), которые вы хотите менять, они хранятся, возможно на разных узлах …

хотя в korni3 нет такого понятия вообще - я постоянно утверждаю, что это локальная личная база данных. Но можно воспринимать “разные узлы” как “разные пользователи” , каждый из которых транит свою копию вашего обекта/записи.

Чтобы провести транзакционную операцию, вы должны собрать “объект-журнал” с подтвержденями от каждого пользователя, о вашей операции. Т.е. документ начинается со списка операций, далее его дополняет своим подтверждением каждый участник - юзер-хранитель реплики (его софт.) и юзер не принимает более одной операции на каждый объект - блокирует на время и если у вас кворум (все или большинство приняли список операций) - то этот документ-журнал публикуется и в нем согласие на операцию всех участников. при этом хранители могут разблокировать объект для следующих транзакций. Это тоже цепочка документов, но они не связаны в общую цепочку вообще всего, как в блокчейне, а лишь мини цепочка по отдельным изменяемым объектам.

Но тогда юзеры-хранители реплик должны быть все время на связи???

Нет такого тут понятия “на связи”, но да. должны. Например если это “казначеи” общей кассы, и они выходят на связь лишь 1 раз в сутки, то только тогда они могут обрабатывать операции / предложения на изменения… не обязательно по одному на ячейку, но скорость транзакций будет от них зависеть… не быстро, ну а что вы хотели? - согласованное состояние распределенной системы получить без согласований ? - на это требуется время (люди всё равно дольше согласовывают)

т.е. в системе korni3 возможны строгие транзакции? ??

да, принципиально такое не исключается. если очень надо - то возможны. Хотя korni3 создавался для оффлайн работы, но в таком случае вам понадобится активно синхронизировать вашу базу с базами других участников, чтобы получить какую то скорость и тут придется назначить “казночеев”, или каких то отдельных особых юзеров… которые что-то должны гарантировать (особый метод обработки ваших запросов) … и вам придется им доверять … т.е. это будет:

распределенная система - да
с равнозначными узлами - уже нет
невозможно заблокировать её работу - да (т.к. не зависит от протоколов связи)
есть быстрые операции - публикация ваших документов, фактов, заявлений, запросов… - легко расчитать что показывать
есть не быстрые операции - транзакционные процессы и журналы/протоколы/подтверждений - исходя их них приложение показывает например деньги на счету…