Как избежать конфликтов репликации?

[Gandliar]

Привет!

Прошу подсказать правильный подход

Есть сервер и есть клиент.

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

Можно ли так сделать?

Либо придется создавать связанный документ, который меняется только на сервере и тянуть в него данные для отображения в видах?

Заранее благодарю

 

[Xalet]

По идее можно выставить в свойствах формы свойство в Conflict Handling Merge / No Conflicts.

 

[TIA]

Установить "Merge Conflict" на форме документа и/или прописать поле $ConflictAction c соответствующим значением

 

[Xalet]

или прописать поле $ConflictAction c соответствующим значением

Да. Если уже созданы документы по форме, то изменив опцию Conflict Handling в форме, значение в уже созданных документах не изменится, новое будет только для создаваемых документов, соответственно в сстарых останется то, каким было(по дефолту вроде как создавать конфликты). В этом случае могут создаваться конфликты в старых документах. Нужно в старых значение заменить.

 

[Akupaka]

Если я правильно помню, то эта фигня работает только при репликации.
А, если я правильно понял задачу, то необходимо на одном и том же сервере подредактировать сервером документ, который в данный момент исправляется пользователем.
Поэтому, если я прав по первому пункту, то просто установка этого свойства для формы не должна сработать.
Если так, необходимо организовать попеременное изменение документа клиентом и сервером.
Как вариант, попробовать переоткрывать документ в тот момент, когда его должен исправить сервер. Но придется предварительно сохранять изменения, внесенные пользователем, иначе пропадут.
Можно закрутить изменение сервером документа на ПостСейв формы, например, серверным агентом (подозреваю, что так и делается сейчас, но возникает конфликт сохранения), и там же, в ПостСейв, переоткрыть документ.

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

 

[TIA]

Речь имено про репликацию

и при этом не возникало конфликтов репликации.

 

[Akupaka]

Речь имено про репликацию

Есть сервер и есть клиент.

:-b )))
Документ в обоих случаях называется Rep or Save Conflict, поэтому...

 

[Gandliar]

Спасибо.

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

задача - чтобы не было конфликтов репликации.

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

а вот попроще - разрулить $ConflictAction, это я попробую, но есть сомнения что это сработает и что это будет стабильный вариант.

 

[Akupaka]

Тады должно помочь:

Установить "Merge Conflicts" на форме документа и/или прописать поле $ConflictAction c соответствующим значением

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

 

[VladSh]

Но очень желательно обрабатывать возникновение конфликтов, т.е. автоматизировать их обнаружение и активно их устранять.

Самый правильный путь - правильное проектирование архитектуры/идеологии при которой конфликты просто не будут создаваться. Естественно без Merge, а с No Conflicts, которая является индикатором правильности работы механизмов предотвращения возникновения конфликтов.
Это здорово, но долго...

 

[Akupaka]

Естественно без Merge, а с No Conflicts, которая является индикатором правильности работы механизмов предотвращения возникновения конфликтов.

Можно подробнее? Как это "No Conflicts" "является индикатором правильности работы механизмов предотвращения возникновения конфликтов"?
Он лишь не создает конфликт, в случае, если бы он создался в обычном режиме, но никак не указывает, что архитектура предотвращает их возникновение!
Или я не прав?

 

[VladSh]

Он лишь не создает конфликт, в случае, если бы он создался в обычном режиме

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

 

[Akupaka]

Точнее, он создаёт конфликт в тех случаях, когда архитектура/механизмы системы позволяют это сделать

Я думал, мы говорим о стандартном механизме создания конфликтов...

 

[VladSh]

Akupaka
Ну сами-то конфликты и создаются стандартно (я не знаю, как их можно создать нестандартно ). Архитектурой/механизмом мы просто мешаем им создаваться, вернее предотвращаем их создавание

 

[Akupaka]

Архитектурой/механизмом мы просто мешаем им создаваться, вернее предотвращаем их создавание

Ну дык, а я о чем? Вот только отключать создание конфликтов вредно, если важно сохранить инфу, а реализовать на все 100% архитектуру, которая бы избегала конфликтных ситуаций не удается (не во всех случаях такое возможно). Иначе будешь думать, что твоя архитектура такая клевая, конфликты не создаются - а где ж им взятся, если опция "не создавать конфликты" включена?! Вот.

 

[VladSh]

реализовать на все 100% архитектуру, которая бы избегала конфликтных ситуаций не удается (не во всех случаях такое возможно)

Как по мне, то реализовать можно во всех случаях, кроме установленной "Enforce a consistent Acess Control List across all replicas". Но надо/целесообразно ли? Вот, к примеру, в БД с контрагентами и ещё некоторыми справочными данными мне этого делать не хочется )) т.к. накладно. Во всех остальных случаях оно работает.

По остальному - мы говорим одно и то же разными словами, потому согласен на все 100

 

[Akupaka]

Как по мне, то реализовать можно во всех случаях, кроме установленной "Enforce a consistent Acess Control List across all replicas"

Как эта опция мешает что-то реализовать? Вообще, то не совсем понятно, что ты имеешь в виду под реализацией Какой-то трюк или че? Расскажи подробнее, пжлста. И что там за накладки?

 

[VladSh]

Akupaka
Трум и ещё пум-пум
По поводу опции и других багов блокировок писал (вернее давал ссылки) здесь.
И ещё пару ссылок (больше для автора темы): 1, 2.
Если всё это сложить, вырисовывается вполне ясная картина...

 

[Akupaka]

По поводу опции и других багов блокировок писал (вернее давал ссылки) здесь.

При поверхностном изучении ссылок, ответа относительно опции "Enforce a consistent Acess Control List across all replicas" найдено не было
Если не сложно, может вспомнишь, что там с ней связано?

зы: сума сойти, ты уже весь айдиаджем забросал идеями! молодец... а я туда даж не захожу

 

[VladSh]

Если не сложно, может вспомнишь, что там с ней связано?

Вот, пришлось делать обратный перевод ))

зы: сума сойти, ты уже весь айдиаджем забросал идеями! молодец... а я туда даж не захожу

Сам последнее время редко что туда бросаю, хотя за последние пол года накопилось уже море...
Убивают они желание писать, т.к. почти ничего не делают из того, что предлагается...
Сейчас я туда бросаю либо идеи по траблам, что лично мне очень мешают в разработке, либо то, что сильно требуют от нас заказчики (чтобы было что им показать, что я свой "долг" выполнил).