Здравствуйте, vaa, Вы писали:

vaa>litedb активно развивается, много звезд. удобен в первом приближении.
vaa>опасение — много открытых багов. возможность наступить на грабли по незнанию.

Не надо трогать это г. не то что руками, а даже и палкой. Имел неосторожность попробовать, и потом не знад что раньше делать — плеваться или материться.
Вот несколько самых заметных глупостей, которые там есть

• соединение с базой только одно может быть, то есть открыл в начале и держи открытым пока сервер жив
  
• транзакции только на бумаге есть, а на деле толку от них нет. Два параллельных потока вычитывают один и тот же ключ,
  инкрементируют соответствующее значение, и записыват назад в базу. Никаких ошибок не возникает.
  Но в результате значение увеличивается только на единицу. Хотя должно быть на два, ну или отвалиться с ошибкой оптимистической блокировки
  
• ну и самый главный облом — это автоинкрементные ключи. Оно их переиспользует зачем-то,
  в итоге если записать в конец коллекции документ, потом его удалить, потом записать новый,
  то у нового будет такой же ID, как и у предыдущего уже удаленного.

В общем, на помойку этот глюкодром.

Здравствуйте, Sharov, Вы писали:

S>Если речь об одной и той же строке данных в бд, то порядок важен.
Именно, что об одной и той же строке. Современные СУБД так и делают: строки сбрасывает на диск lazy writer или вообще ОС.
Порядок важен только для лога.

Здравствуйте, Sinclair, Вы писали:

S>>Если речь об одной и той же строке данных в бд, то порядок важен.
S>Именно, что об одной и той же строке. Современные СУБД так и делают: строки сбрасывает на диск lazy writer или вообще ОС.
S>Порядок важен только для лога.

Я думаю порядок зависит от уровня изоляции. Т.е. как возможен случайный порядок при serialization?

Здравствуйте, Sharov, Вы писали:

S>Я думаю порядок зависит от уровня изоляции. Т.е. как возможен случайный порядок при serialization?
Уровень изоляции влияет только на порядок захвата и отпускания локов (или видимости версий при использовании версионирования).

Механизм восстановления после сбоя на основе Undo/Redo не полагается на то, в каком порядке сбрасываются на диск страницы данных.
При рестарте сервера мы будем сканировать лог, откатывать к старому состоянию страницы для незакоммиченных транзакций, и накатывать к новому состояние страницы для закоммиченных транзакций.

Подробное изложение механизма работы я советую почитать в Гарсиа-Молина, глава 17.

Здравствуйте, vaa, Вы писали:

vaa>litedb активно развивается, много звезд. удобен в первом приближении.
vaa>опасение — много открытых багов. возможность наступить на грабли по незнанию.

Тоже посоветую обходить LiteDb стороной.
С чем столкнулся лично я — некорректно записывает изменения, если файл лежит на шаре (у меня,вдобавок, он лежал на шаре Windows, которую монтировали из Linux).
Причина — в пятой версии завезли механизм блокировок, который с шарами работает некорректно. Пообещали поправить в версии 5.1, а ее все нет.

Ну и в этом году развивается он вовсе не активно, всего два патч-релиза, при огромнейшем количестве открытых ишью и пулл-реквестов.
И даже стали появляться вот такие темы, наподобие Is LiteDb abandoned?

Здравствуйте, Legion13, Вы писали:


L>Тоже посоветую обходить LiteDb стороной.

Да я на старте пробовал его использовать но быстро понял, что профит нулевой при попытке выйти за пределы
стандартной модели. Работает только на свойствах и паблик конструкторах. Т.е. если DDD то чтобы сохранить нужно будет обязательно в ДТО перегнать данные.
Лишнее преобразования и структуры. Минус как для рантайма так и для разработки.
Сделал вывод, что лучше один раз руками описать процесс сохранения и восстановления. Чем мучаться с такими штуками.
Даже ОРМы у меня под большим сомнением.