В этой теме был затронута тема по сабжу, которая оказалась оффтопом, но заслужила отдельной темы
тут будет её форк.
ВМоисеевРассмотрим ситуацию:
Вася и Петя загрузили оригинал информационного файла и начали редактировать каждый свою часть.
Вася шустрый и быстренько закончил своё дело, сохранив свою работу в на сервере. Оригинал изменился.
Петя пошёл попить чайку и свою работу закончил после Васи. Но он не может сохранить свою отредактированную копию в качестве оригинала, ибо будет потеря информации Васи.

сразу как Петя сохранил документ Васе всплывает уведомление (в идеале через websocket), что документ изменён и его надо перезагрузить

и вот тут я запутался...
этот мержинг?
авторMerge — оператор языка SQL, который позволяет слить данные одной таблицы с данными другой таблицы. При слиянии таблиц проверяется условие, и если оно истинно, то выполняется Update, а если нет - Insert.
Пару страниц назад ты говорил, что UPDATE не нужен.
А прям перед моим постом ты писал:

...где п.2 это практически точная копия моего варианта и таки там есть блокировка (Васе заблокирована возможность сохранить документ поверх Пети).


ну т.е. все увидят только изменения Васи. А Петя может до усрачки гордиться своими изменениями, но их так никто и не увидит...
пока он их не пересохранит!
тогда Васины изменения пойдут на хер, а Петины изменения увидят все...
пока Вася их не пересохранит!
тогда Петины изменения пойдут на хер, а Васины изменения увидят все...
пока Петя их не пересохранит!
...
где конец этой истории?


Пардон за толстую броню, но я всё ещё слабо представляю, как это должно выглядеть...
Даже при том, что с CRM знаком не по наслышке.
Допустим, у меня форма по заполнению паспорта.
Вася заполнил, сохранил.
Петя заполнил, сохранил.
Коля заполнил, сохранил.
Да кто угодно заполнил, сохранил.

Во1, мы тупо сохраняем всем разные версии (даже без оглядки на сохранение одновременно открытых документов)? Или сохраняем только те, которые одновременно 2-3-5 челов редактировало?
во2, как теперь будет выглядеть форма сохранения паспорта? Там под каждым инпутом будут вылазить все остальные варианты?
в3, какая именно версия будет актуальной то - самое главное?

а п.2 - это не то, о чём я писал?

ну, во1, кол-во полей мало. Потому что большая форма разбита на блоки и в /show/ показывается только текст (БЕЗ редактирования)
А кликая по каждому блоку открывается /edit/, где отдельная мини-форма с минимумом полей.
Там максимум десяток инпутов/селектов/чекбоксов, а обычно 3-5.
во2, делает он так: открывает в соседнем окне изменённую копию и оттуда забирает новые поля к себе.

Я просто не очень понимаю, как будет разруливаться это множество версий... Ну откроется последняя, а чё со всеми предыдущими делать? Какая из них нужна, какая нет...
Идея ВСЁ хранить конечно имеет свои плюсы, но это же путаница.

это отдельный человек-робот там сидит чтоли и правит чужие писульки?

как же не имеет?! После уведомления он не сможет сохраниться в этом окне.
Он откроет в другом окне последнюю сохранённую версию (которая будет Петиной) и вот в неё перенесёт свои правки.
Ну две версии тоже ок, их визуально можно рядом поставить. Но:
а) их сложнее обслуживать;
б) сложнее для пользователя с ними разбираться;
в) сложности с UI для программиста.

Как вообще это будет происходить? Петя сохранился, Васе то опять же надо уведомление дать? А потом показать где-то новую версию...

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


ну вот тут бы надо определиться, что в wiki/confluence это одно, а в CRM это редкость. А мы тут про CRM как раз.

ну я на это внимание обратил

вопрос то кстати был не ко мне, а к ВМоисееву :)

Я не могу с вами согласиться.
Я могу сказать, что ещё фиговей, когда Вася сохранится, а потом Петя сохранится.
Вася откроет снова, а там уже другая инфа, которую он никогда не видел и надпись "это Петя".
Всё. Разбитые ёбла. Война. Хаос. Разрушения.

Я понимаю, что в wiki это не канает, там много совместных редактирований и интерфейс под это заточен.
Но в CRM это разовые случаи.

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

ну например, Вася редактирует <textarea>, сохраняет новую версию с критическими правками.
И там, например, написано "не трогать клиента, потому что он плюётся ядом".
А в это время Петя редактирует её же и не видит новой инфы, сохраняет свою инфу "клиенту звонил, договорились о встрече на завтра".
В итоге Петя умер. Васю посадили. Клиента сожгли. Руководство выебали. Компанию закрыли. Имущество распродали. Занавес.

это в которой надо по 3 записи дополнительные вводить для каждой такой блок формы?
где указано: кто заблокировал, время блокировки и какой именно блок блокируем.
авторОсновной минус тут один: запись может висеть в заблокированном состоянии сколько угодно, поэтому желательно наличие какого-нибудь администратора, который может принудительно разблокировать любую запись.
Кстати, а чё это мы уже на пессимистичную блокировку переместились, были же вроде на мультиверсионном варианте БЕЗ блокировок...

и это навсегда теперь в базе? Всё что там когда-либо сохраняли вы держите в своём Event Store?

да читал . Озвучил вам вариант №2.

а что за блокировки вообще, если у вас ES ??