|
GUID. 2 Объекта разного типа данных, но с одинаковым GUIDом. | ☑ | ||
---|---|---|---|---|
0
Wirtuozzz
28.04.17
✎
12:36
|
Всем привет.
Хочу проконсультироваться свами по такому вопросу: В базе источнике выгружается документ, а загружается как 2 документа разного типа, но с одинаковым ГУИД. Какие могут быть подводные камни такой ситуации, что в базе будет 2 одинаковых ГУИДа, разного типа данных? Всем спасибо за ваши комментарии. |
|||
1
AuneM1
28.04.17
✎
12:37
|
Это норма. Редко, но бывает.
|
|||
2
Oftan_Idy
28.04.17
✎
12:38
|
(0) Такое событие очень маловероятно, но теоретически возможно
|
|||
3
DrShad
28.04.17
✎
12:39
|
(1) практически не бывает, НО норма
|
|||
4
HEKPOH
28.04.17
✎
12:41
|
(0) у меня в выгрузке так же. Именно так и нужно. Иначе, как потом при повторной выгрузке сопоставлять объекты? Способы придумать можно, но зачем? Одинаковый Гуид - самое оно
|
|||
5
1CIlya
28.04.17
✎
12:41
|
(0) Вмешивайтесь в стандартное поведение конвертации, присваивайте новый ГУИД перед записью у одного из документов. Предсказать где это может вылезти не получится, поскольку у нас нет исходников 1С, но то, что вылезет, не сомневайтесь.
|
|||
6
Wirtuozzz
28.04.17
✎
12:42
|
А ТИИ и прочие механизмы проверок базы будут работать штатно. Так ведь?
|
|||
7
МихаилМ
28.04.17
✎
12:42
|
1с8 в запросе группировала по гуиду разные типы док разных типов.
обсуждалось на форуме несколько лет назад. может исправили. |
|||
8
Wirtuozzz
28.04.17
✎
12:45
|
(5) откуда уверенность что вылезет? были случаи?
|
|||
9
Wirtuozzz
28.04.17
✎
12:48
|
т.е. получается, пока 1С разделяет данные по типу и ГУИД, то будет работать, отвалится когда 1С перейдет на GUID, т.е. будет доступна конструкция, типа:
СсылкаНаОбъект = ПолучитьСсылку("УникальныйИдентификатор"); |
|||
10
МихаилМ
28.04.17
✎
12:51
|
(7) соврал .
там другая проблема . еще хуже. v8: Восстановление по УИД учитывая, что id сеансом присваиваются последовательно. |
|||
11
1CIlya
28.04.17
✎
12:51
|
(8) Случаев не припомню. Вспоминайте закон Парето - если неприятность может случиться, она случится.
|
|||
12
Wirtuozzz
28.04.17
✎
12:53
|
(11) Это понятно, у меня любопытство играет.
Я понимаю, что можно придумать как решить задачу, без 2-ух объектов с одинаковым ГУИДом. И это будет правильно, т.к. мы исключаем даже вероятность ошибки в таблицах, НО любопытство толкает меня на разговор. |
|||
13
Demasiado
28.04.17
✎
13:02
|
Это нормальное явление когда вы через конвертацию создаете из одного объекта несколько объектов другого типа. Никакой ошибки не будет, иначе такие вещи как конвертация данных не работали бы в принципе. Даже если вы по гуиду ищете какой-то объект - вы всегда указываете тип того что ищете. Поэтому если у коллег были проблемы с двумя одинаковыми гуидами у разных объектов - то от кривого кода.
|
|||
14
Wirtuozzz
28.04.17
✎
13:05
|
(13) Все дало в том, что выгрузка идет совсем не через конвертацию. Тут через COM идет обмен, но сути дела это не меняет.
|
|||
15
h-sp
28.04.17
✎
13:07
|
(14) ну это же всё равно конвертация. Какая разница.
|
|||
16
Wirtuozzz
28.04.17
✎
13:10
|
В принципе я думаю, что в случае необходимости, я смогу по тому же СОМ найти нужные мне документы, и присвоить объектам новую сслыку, порвав порочную связь.
/////////////////////////////////////// УстановитьСсылкуНового (SetNewObjectRef) Синтаксис: УстановитьСсылкуНового(<Ссылка>) Параметры: <Ссылка> (обязательный) Тип: СправочникСсылка.<Имя справочника>. Ссылка, которая будет назначена при записи нового объекта. Описание: Устанавливает значение для нового (созданного и еще не записанного) объекта, которое будет назначено при записи в качестве ссылки. Значение не может равняться ссылке какого-либо из имеющихся в базе данных объекта данного типа. Уникальность ссылки проверяется при записи объекта. Доступность: Сервер, толстый клиент, внешнее соединение, мобильное приложение(сервер). |
|||
17
Wirtuozzz
28.04.17
✎
13:10
|
(15) Согласен! Просто обозначил что выгрузка через СОМ, а так да, конвертация.
|
|||
18
Demasiado
28.04.17
✎
13:15
|
Да не надо ничего рвать, проблема надуманная. Когда ты по гуиду будешь искать объект - ты же не венегрет ищешь? ты будешь явно указывать ищу такой-то тип, такой-то гуид.
|
|||
19
Wirtuozzz
28.04.17
✎
13:24
|
(18) Точно точно, я просто перестраховываюсь.
|
|||
20
бомболюк
28.04.17
✎
13:24
|
(0) лучше бы назначать разные ГУИДы, как мне кажется, так как в отдельных случаях, например, когда обе ссылки входят в некий результат запроса, который должен быть отсортирован по моменту времени у нас не будет повторяемости результата от раза к разу, так как моменты времени будут равны. то один документ будет вставать первым, то другой, а с точки зрения 1С документы имеют уникальные ссылки, а значит и моменты времени.
|
|||
21
Wirtuozzz
28.04.17
✎
13:29
|
(20) Почему вы решили что будут равны моменты времени? Они не будут одинаковыми, т.к. ссылка на документ это как я понимаю GUID + Тип документа. а Типы в данном случае разные.
|
|||
22
Demasiado
28.04.17
✎
13:30
|
(20) если проблема в сортировке - вытаскивай дату документа и сортируй по ней.
|
|||
23
бомболюк
28.04.17
✎
13:30
|
(21) я честно говоря не уверен что тип туда тоже входит, надо эксперементировать
|
|||
24
бомболюк
28.04.17
✎
13:30
|
хотя если входит то повторяемость конечно же будет
|
|||
25
Serg_1960
28.04.17
✎
13:31
|
"НО любопытство толкает меня на разговор" - могу предложить тему разговора :)
Я так понимаю, что многие внешние обработки по восстановлению битых ссылок станут выдавать неоднозначный результат. |
|||
26
ViSo
28.04.17
✎
13:34
|
(3) Практически и часто :) вы просто не умеете их готовить
|
|||
27
Wirtuozzz
28.04.17
✎
13:34
|
(25) интересный момент. Да, действительно, если пытаться восстанавливать ссылки, то могут быть "приколы".
|
|||
28
бомболюк
28.04.17
✎
13:38
|
(21) тип входит в момент времени, проверил профайлером ;-) но все равно равные ГУИДы это некузяво ;-)
|
|||
29
Wirtuozzz
28.04.17
✎
13:39
|
(28) Что значит некузяво? Типа плохо ?
|
|||
30
Serg_1960
28.04.17
✎
13:39
|
Есть много и других алгоритмов, которые априори, косвенно или прямо, используют уникальность ссылки в базе. Например, отборы, соединения в запросах.
|
|||
31
Serg_1960
28.04.17
✎
13:42
|
Упс, не дописал:
...и как добиться их правильного функционирования, если исходить из того, что ссылка перестала быть уникальной в базе. |
|||
32
Aleksey
28.04.17
✎
13:42
|
(25) нет не будут. Так как в таких обработках нужно явно указать тип
|
|||
33
бомболюк
28.04.17
✎
13:43
|
(29) типа плохо
|
|||
34
Aleksey
28.04.17
✎
13:43
|
(31) В 8-ке нет общего журнала, поэтому пофиг
|
|||
35
Aleksey
28.04.17
✎
13:44
|
(33) Не знаю у себя уже 10 лет держу одинаковые ссылки. Всем пофиг
|
|||
36
Wirtuozzz
28.04.17
✎
13:45
|
(30) не понял, можно пример алгоритма или отбора?
|
|||
37
Лефмихалыч
28.04.17
✎
13:55
|
(0) видел, как это работает много где. И сам так делал. Нет проблем ни каких.
|
|||
38
Serg_1960
28.04.17
✎
14:07
|
(36) https://helpf.pro/faq/view/483.htm - в алгоритмах используется GUID, УникальныйИдентификатор() и "теряется" тип ссылки.
|
|||
39
Aleksey
28.04.17
✎
14:55
|
(38) Ну это самописный алгоритм. К типовым не имеет отношения.
В частности типовой алгоритм формирования ГУИД позволяет вытащить дату создания из гуид. При этом если ГУИД формировать вручную, то тогда уже не получиться вытащить дату. Но это же не означает что ручное формирование ГУИД это плохо, так как там нет даты? |
|||
40
ptiz
28.04.17
✎
15:36
|
(27) Не могут. Для составного типа кроме ссылки хранится указание на тип.
|
|||
41
Михаил Козлов
28.04.17
✎
15:49
|
Делал такое: продажи одной организации другой в одной БД.
|
|||
42
Wirtuozzz
28.04.17
✎
16:37
|
(38) при рабочей базе источнике, я могу в любой момент сделать еще раз выгрузку, и все "встанет" на свои места. К тому же, переноситься у меня будет не справочная информация, а документы. А ссылок на эти документы нет. Т.е. это два независимых, не ссылающихся друг на друга документа, просто с одинаковым ГУИДом.
|
|||
43
Serg_1960
28.04.17
✎
17:14
|
Если внимательно прочитать мои сообщения, то я нигде не запрещал и не говорил, что так делать нельзя. Просто обратил внимание на интересный аспект. Токмо любопытства ради :)
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |