• Бесплатный ВЕБИНАР по OSINT с Екатериной Тьюринг: ➡️9 февраля в 19:00 (мск) пройдет урок

    Как безопасно искать информацию в открытых источниках

    🔥 Записаться 🔥

Изменение полей документа - посоветуйте подход

  • Автор темы Автор темы Gandliar
  • Дата начала Дата начала

Gandliar

Lotus Team
16.02.2004
573
26
BIT
182
Здравствуйте!
В одном документе есть поля, которые должны меняться одновременно разными пользователями.
Например, есть документ и есть документ справочника при изменении значений в справочнике должны поменяться значения в документе.
Однако это может происходить одновременно. Кто то работает с документом, кто-то меняет справочник.

На текущий момент думаю, что надо отказаться от сохранения по форме и всегда сохранять только поля из текущего документа в оригинальный документ на диске.
Например в форме оставить только те поля, которые зависят от текущего пользователя, остальные показывать через computedText или через computedForDisplay.
В секции QuerySave поставить Continue=false и вызвать функцию, которая возьмет doc из текущего документа, документ с диска docSource из вида по universalId, список полей из формы,
затем перезаписать указанные поля из текущего документа на диск и сохранить docSource.save(true, true)
Таким образом поля в одном и том же документе могут меняться одновременно разными пользователями без конфликтов.

Что Вы думаете об этом, какие могут быть подводные камни?
 
могут меняться одновременно разными пользователями без конфликтов.
конфликт возникает только при сохранении в UI
вноси изменения в бэке и не будет проблем
давно отказался от практики редактирования в UI уже сохранённого дока - оставил только для новых доков и доков с richtext (когда лень сохранять именения ричь в бэке)))
нормальный ход, не будет камней) если разные юзвери гарантировано будут сохранять разные айтемы
 
спасибо!

Может еще подскажете подход по проверке какие айтемы изменились?
Сейчас я склоняюсь к тому чтобы оба документа перегнать в стринг dxl
и сравнить текстовое содержание item
после чего видимо либо удалять item и копировать на его место новый или лучше replace ?
и отдельный вопрос как быть с ричтекстами и mime как их лучше проверять на изменение
С одной стороны, у каждого item есть дата модификации, но почему то при сохранении если брать doc из uidoc то она у всех равна, даже если item и не менялся

Как лучше?
 
спасибо!

Может еще подскажете подход по проверке какие айтемы изменились?
Сейчас я склоняюсь к тому чтобы оба документа перегнать в стринг dxl
и сравнить текстовое содержание item
после чего видимо либо удалять item и копировать на его место новый или лучше replace ?
и отдельный вопрос как быть с ричтекстами и mime как их лучше проверять на изменение
С одной стороны, у каждого item есть дата модификации, но почему то при сохранении если брать doc из uidoc то она у всех равна, даже если item и не менялся

Как лучше?
у айтемов есть SeqNum @rinsk по нему изменения чекает, но там есть нюансы ;)
а чтобы совсем запутать - есть такая штука:
Java:
    /**
     * Returns the sequence number of the item
     *
     * @return sequence number (byte)
     */
    public int getSeq() {
        loadItemNameAndFlags();

        return (int) (m_seq & 0xff);
    }
в DominoJNA klehmann/domino-jna
и возможно не придется самому допиливать код Константина ;), вот только вопрос что привычнее/проще окажется
 
Последнее редактирование:
1. Подхватывать формулами значения полей других доков - хорошая идея для небольшого количества данных и простой структуры БД. Иначе открытие доков будет жутко тормозить - постоянные обращения к базам/видам..., что очень неоптимально, т.к. куча ненужных операций чтения. "Студенческие решения", так сказать) Хотя у знаменитых вендоров масса такого кода, - на заре разработки многие так писали, да и продолжают, к сожалению.
2. Я сравнение полей делаю по значениям - проверяю фиксированный список, либо если диалог поднимается на сабформе/форме, то программно получаю имена полей из соотв. элемента дизайна.
3. В пределах одного сервера можно обойтись блокировками, иначе - запросная ("транзакционная") система внесения изменений (подробно уже говорили в одной из смежных тем).
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!