Arm79А зачем все усложнять?

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

Как то так.+1

Я примерно так и реализовал контур конкурентного редактирования в Абрикосе.
Плюс у нас есть история изменений и в сообщении о том, что кто-то изменил данные параллельно с вами, вставляется ссылка на историю, где можно посмотреть последнюю и при желании откатиться на предыдущую версию.

Также можно поглядеть как это реализовано в таких решениях как Google Docs, Confluence, Jira...

ИзопропилArm79пропущено...

Этого достаточно, ибо тот кто сохраняет последним - увидит все правки на момент сохранения.

угу и сравнение изменённых полей произведёт полное, в итоге rowversion - как корове седло, сравнение всё равно по полной программе делатьЗачем и кто произведёт? Петя глазками увидит в истории, что конкретно изменил Вася и примет решение. От кода не требуется что-то сравнивать.

ИзопропилskyANA,

какая ещё история?
Петя правил поле A
Вася правил поле BКоторую надо завести.

Изопропилконфликта нет, какие в жопу глазки?Конфликта никогда нет, т.к. кто последний, того и тапки.
А глазки в случае разборок не в жопу должны смотреть, а в историю.

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

Konst_Oneесли у документа существуют стадии редактирования, зависимые от разных факторов, то необходимо фиксировать состояние документа на каждой стадии и полностью запрещать его изменение пока он не перейдёт на следующий этап обработки.Как сделал я: пока пользователь что-то редактирует, то изменения пишутся в одну draft версию.
Когда он жмёт Save, то изменения накладываются на сам документ, а draft версия переходит в состояние current.

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

ViPRosskyANAпропущено...
Как сделал я: пока пользователь что-то редактирует, то изменения пишутся в одну draft версию.
Когда он жмёт Save, то изменения накладываются на сам документ, а draft версия переходит в состояние current.

Когда явно нет кнопки Save, то можно окончательно фиксировать изменения по истечению какого-то таймаута, в течение которого пользователь бездействует, то есть закончил с редактированием.
хахахаха
ты сделал DataTable :)ухухуху, трололо

а. речь об Абрикосе, то есть о SaaS web-решении;
б. данные хранятся в MongoDB;
в. если у пользователя по какой-то причине крашится браузер (приложение) или комп во время редактирования, то draft сохраняется и пользователь может вернуться к его редактированию, после восстановления после сбоя

какой на фиг DataTable?

ViPRosskyANA,

если добавить еще и связи между драфтами (а без них никак, ты ж не огрызки редактируешь небось), ограничения целостности и т.д. получишь DataSet
Поздравляю! Ты на верном пути!Почитай, что такое MongoDB и подумай, что ты пишешь.

ViPRosskyANA,

да какая разницы
везде массивы и списки и их отношенияПочитай, почитай.
И расскажи нам, зачем документ отображать на DataSet и обратно?

ViPRosskyANA,

смотря что такое "документ" и "оборот" :)Извини, но ты выглядишь как глупый тролль.
MongoDB - это документоориентированная БД. Что же такое документ? :)

ViPRosskyANA,

не знаю, обясни
а насчет глупости еще посмотрим :)Глупо вестись на такой глупый троллинг.

16813978