@unique

[Akupaka]

а где пан lmike с фразой "это же классика" и ссылками на форум интертраста? )))
там есть обсуждения по этому поводу.

Тогда после копи-паста (или еще чего...) связи между доками не порушатся

не порушится, но такая каша получится, если появятся доки с отличающимся унидом и значением поля )

Но ищо раз ета функция как писал ToxaRat толоько для 1 бази. для реплик уже не подойдет имхо

а кто проверил вообще его слова?!

 

[TIA]

Можно в док-те создать поле Computed when composed и в него сохранять юнид.
Для связи док-тов использовать данное поле.
Тогда после копи-паста (или еще чего...) связи между доками не порушатся.

Этого мало. Что будет после двух и более копипастов ?

 

[Omh]

Я копипасту обычно обрабатываю QueryPaste агентами.
Во-первых, глобально на базу, во-вторых можно гибкий код писать (с анализом документа, родителя и т.д.)
Что не очень нравится, что эти агенты работаеют уже на запащеных документах, т.е. они уже в базе, и, если пастить всё-таки нельзя, но приходится их удалять, оставляя делишн стабы.
Решается вставкой небольшого кусочка на API, который удаляет без стаба

 

[Cleric84]

Akupaka

а кто проверил вообще его слова?!

я не проверял :mellow: но на логику подумай сам есть сервер "А" и сервер "Б"
на сервере "А" есть пользователь Petro PUPKIN на сервере "Б" Pavel PUPKIN
Теперь @unique берет 1 букву имени, и 3 первих букви фамилии далее идут через дефиз каша из 6 символов(букви и цифри) которая вичисляется наверно из времени на сервере.
теперь 2 етих юзера в один прекрасний день и час надумают сделать документ и что же у нас получится?

 

[Akupaka]

короче, я попытался проверить двумя персонажами с разных машин, в пределах одной реплики данные сгенерированные командой @unique получились уникальны.
потом пытался в локальной реплике создавать документы, тоже уникальны.
так, что, если есть желание, то попробуй создать простое распределенное приложение и потестить. думаю, что будут уникальны записи.
меня пока что смущает лишь сообщение

сам не нарывался и не проверял, но слышал, что при автоматической генерации доков с @unique в качестве уникального ключа, нарывались на одинаковые значения. т.е. документы создаются слишком быстро и @unique возвращает одно и то же значение.

Решается вставкой небольшого кусочка на API, который удаляет без стаба

а как же распределенка?..

 

[Omh]

а как же распределенка?..

Так они же свежезапащенные, ещё никуда не оспели среплицироваться.
Хотя, теоретически, может что то вылезти, если пастить во время репликации.
Тадо будет провентилировать этот вопрос.

Та база, где я сразу удаляю стабы, админская, её обычно юзает один пользователь и она не имеет реплик (типа standalone тулза).

А на большой системе действительно может вылезти, признаю, не подумал (это всё макдональдс по утрам!) :mellow:

 

[Akupaka]

это всё макдональдс по утрам!

не читайте советских газет, и не ешьте американской пищи, особенно по утрам! ))
а вообще, конечно, все зависит от задачи

 

[PaVaP]

Этого мало. Что будет после двух и более копипастов ?

Опечатка вышла :mellow:
Я имел ввиду не копи-паст, а кат-паст. В этом случае думаю неважно, сколько раз меняется юнид, т.к. связи основаны на CWC поле и если не нашли по этому полю функцией GetDocumentByUNID, то тогда ищем уже в виде по ключу(полю). Только вот интересно, может ли поиспользованный ранее юнид назначиться потом новому документу, и если может то когда... Может кто знает механизм формирования юнида?

Что касается копи-паста, то конечно дубли никому не нужны и я например просто в вида на Querypaste запрещаю вставку, чтобы юзеры дубли не плодили. А если нужно типа копии создать, то это через кнопку "Создать на основе существующего", где всё корректно обрабатывается...

... такая каша получится, если появятся доки с отличающимся унидом и значением поля )

Какая каша? Зачем нам юнид, нам юнид не нужен Можно ведь полем оперировать...

 

[TIA]

Я имел ввиду не копи-паст, а кат-паст. В этом случае думаю неважно, сколько раз меняется юнид, т.к. связи основаны на CWC поле и если не нашли по этому полю функцией GetDocumentByUNID, то тогда ищем уже в виде по ключу(полю). Только вот интересно, может ли поиспользованный ранее юнид назначиться потом новому документу, и если может то когда... Может кто знает механизм формирования юнида?

Вобщем, аккуратнее надо.
Повторное назначение одинакового юнида имеет незначительную вероятность. Практически можно считать, что она нулевая. В его формировании участвует текущее время с точностью до 1/100 и часовым поясом, некое сгенерированное произвольное значение, часть от ReplicaID БД.
Подробнее в Lotus C API, БД User Guide, документ "Anatomy of a Note ID".

 

[PaVaP]

Подробнее в Lotus C API, БД User Guide, документ "Anatomy of a Note ID".

Спасибо.
Попутно нашел интересную табличку

Ссылка скрыта от гостей