Регистрация  |  Вход

Копирование записи и перелинковка ее связей

Задача заключается только в смене ID для записи (в пределах одного объекта) в определенных бизнес-процесс ситуациях.

Возникла такая теоретичская схема:

страница в гет параметре принимает ID записи определеного (ожидаемого) объекта, и затем:

(1) полностью клонирует запись в пределах одного объекта.
(2) проводит поиск и перелинковку всех связанных (в т.ч. ссылающихся) записей.
(3) благополучно удаляет из БД исходную запись.

(Кстати а можно ли сменить ID у записи каким то более простым путем, чем тот, что описан выше???)

Таким образом:
(1) есть ли класс или алгоритм, который копирует (клонирует) запись?
(2) что делать если в момент написание кода у объекта (к которому относится наша запись) было 3 ссылкающися объекта (записи которого могут брать в лук-ап ID записей первого объекта), а затем в результате расширения приложения добавили еще пару объектов? А мой код то и не знает об этом.

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

Ваше мнение.

Задача заключается [b]только в смене ID[/b] для записи (в пределах одного объекта)  в определенных бизнес-процесс ситуациях.

Возникла такая теоретичская схема:

страница в гет параметре принимает ID записи определеного (ожидаемого) объекта, и затем:

(1) полностью клонирует запись в пределах одного объекта.
(2) проводит поиск и перелинковку всех связанных (в т.ч. ссылающихся) записей.
(3) благополучно удаляет из БД исходную запись.

(Кстати а можно ли сменить  ID у записи каким то более простым путем, чем тот, что описан выше???)

Таким образом:
(1) есть ли класс или алгоритм, который копирует (клонирует) запись?
(2) что делать если в момент написание кода у объекта (к которому относится наша запись) было 3 ссылкающися объекта (записи которого могут брать в лук-ап  ID записей первого объекта), а затем в результате расширения приложения добавили еще пару объектов? А мой код то и не знает об этом.

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

Ваше мнение.

А зачем менять ID объекта? Какая может быть здесь практическая цель?
ID это внутреннее служебное поле SF, которое кстати неизменное (нельзя задать ни изменить).
Зачем бизнесу вообще трогать это поле?

Как по мне задача "только в смене ID для записи" вообще не имеет смысла.

А так да, только клонированием и проходом по всем lookup полям ссылающихся объектов можно это сделать. И правильно ты отметил - если все lookup (master-details) поля неизвестны, то получится большой геморрой.

А зачем менять ID объекта? Какая может быть здесь практическая цель?
ID это внутреннее служебное поле SF, которое кстати неизменное (нельзя задать ни изменить). 
Зачем бизнесу вообще трогать это поле?

Как по мне задача "только в смене ID для записи" вообще не имеет смысла.

А так да, только клонированием и проходом по всем lookup полям ссылающихся объектов можно это сделать. И правильно ты отметил - если все lookup (master-details) поля неизвестны, то получится большой геморрой.

Dmitry Shnyrev
А зачем менять ID объекта? Какая может быть здесь практическая цель?
ID это внутреннее служебное поле SF, которое кстати неизменное (нельзя задать ни изменить).
Зачем бизнесу вообще трогать это поле?

Как по мне задача "только в смене ID для записи" вообще не имеет смысла.

А так да, только клонированием и проходом по всем lookup полям ссылающихся объектов можно это сделать. И правильно ты отметил - если все lookup (master-details) поля неизвестны, то получится большой геморрой.

Ну на самом деле не такой уж и большой гемморой, всего навсего нужно получить ВСЕ поля существующей записи сделать клон. После этого найди все записи которые ссылаются на эту запись и сделать им так же клон. Это для случая когда нужно все клонировать. Обычно все бывает занчительно проще.

[quote="Dmitry Shnyrev"]А зачем менять ID объекта? Какая может быть здесь практическая цель?
ID это внутреннее служебное поле SF, которое кстати неизменное (нельзя задать ни изменить). 
Зачем бизнесу вообще трогать это поле?

Как по мне задача "только в смене ID для записи" вообще не имеет смысла.

А так да, только клонированием и проходом по всем lookup полям ссылающихся объектов можно это сделать. И правильно ты отметил - если все lookup (master-details) поля неизвестны, то получится большой геморрой.[/quote]

Ну на самом деле не такой уж и большой гемморой, всего навсего нужно получить ВСЕ поля существующей записи сделать клон. После этого найди все записи которые ссылаются на эту запись и сделать им так же клон. Это для случая когда нужно все клонировать. Обычно все бывает занчительно проще.

Dmitry Shnyrev
Зачем бизнесу вообще трогать это поле?

Вот представте ситуацию. На книжках наклеен QR код который содержит обычный урл на запись об этой книжке (т.е. базовый урл орга + ID). Библиотекарь сканирует его и видит запись о книжке.

И вот Библиотекарь хочет заметь все старые ярлыки с кодом на новые, которые чем-то лучше. Но как это сделать в массовом порядке?

Они предлагают распечатать сотни новых ярлыков (с урлами, которые ведут на новые пустые записи книжного объекта - но это понятно только мне).

Затем сканировать на книжке старый код, заклеить его любым новым и сканировать и его. И, трах-тибидох, теперь новый лабел "содежит" все информацию об этой книжке.

Я уже не говорю как это будет реализовано на стороне сканера. Говорю только о том, что такой "перенос" информации с одного ярлыка на другой, новый - на уровне БД означает "перезапись" (копирование) записи (или смена его ID - можно и так сформулировать проблему).

Мне это кажется слишком сложным.

Но и сказать людям,чтобы распечатывали ярлыки с реальными записями (т.е. с урл ведущим на существующие записи) - а потом для каждого такого ярлыка находили именно его книжку - это тоже проблема.

[quote="Dmitry Shnyrev"]
Зачем бизнесу вообще трогать это поле?
[/quote]

Вот представте ситуацию. На книжках наклеен QR код который содержит обычный урл на запись об этой книжке (т.е. базовый урл орга + ID). Библиотекарь сканирует его и видит запись о книжке.

И вот Библиотекарь хочет заметь все старые ярлыки с кодом на новые, которые чем-то лучше. Но как это сделать в массовом порядке?

Они предлагают распечатать сотни новых ярлыков  (с урлами, которые ведут на новые пустые записи книжного объекта - но это понятно только мне).

Затем сканировать на книжке старый код, заклеить его [b]любым [/b]новым и сканировать и его. И, трах-тибидох, теперь новый лабел "содежит" все информацию об этой книжке. 

Я уже не говорю как это будет реализовано на стороне сканера. Говорю только о том, что такой "перенос" информации с одного ярлыка на другой, новый - на уровне БД означает "перезапись" (копирование)  записи (или смена его ID - можно и так сформулировать проблему).

Мне это кажется слишком сложным.

Но и сказать людям,чтобы распечатывали ярлыки с реальными записями (т.е. с урл ведущим на существующие записи) - а потом для каждого такого ярлыка находили именно его книжку - это тоже проблема.

хм. интересная задача. Спасибо за практический пример.

Но я бы в этом случае поступил немного по другому. С более ООП точки зрения.

QR код это то же какой-никакой реальный объект, который несет пользу людям. Так почему нельзя для него завести отдельный объект в SF с lookup на объект book? + немного кастомного кода, который позволит открыть правильную книгу если кто-то пришел по QR коду.
Кодирования минимум. НО одни плюсы:
- вот тебе и статистика по кодам (количество, кто когда создвал, неиспользуемые коды),
- вот тебе и кастомный редирект на который ты можешь повесить например сбор статистики (кто когда переходил).
- надо книге новый QR повесить, создал новый задал lookup (2, 3, 10 кодов для одной книги - пожалуйста)

можно только перечислять и перечислять.

А с твоим изменить ID книги только для того чтобы у нее новая ссылка была - это вообще не рационально!!!

хм. интересная задача. Спасибо за практический пример.

Но я бы в этом случае поступил немного по другому. С более ООП точки зрения.

QR код это то же какой-никакой реальный объект, который несет пользу людям. Так почему нельзя для него завести отдельный объект в SF с lookup на объект book? + немного кастомного кода, который позволит открыть правильную книгу если кто-то пришел по QR коду.
Кодирования минимум. НО одни плюсы:
- вот тебе и статистика по кодам (количество, кто когда создвал, неиспользуемые коды), 
- вот тебе и кастомный редирект на который ты можешь повесить например сбор статистики (кто когда переходил). 
- надо книге новый QR повесить, создал новый задал lookup (2, 3, 10 кодов для одной книги - пожалуйста)

можно только перечислять и перечислять. 

А с твоим изменить ID книги только для того чтобы у нее новая ссылка была - это вообще не рационально!!!

Вот я тоже так и думал - создать "промежуточный" объект, и все "перестановки" производить именно в нем.

Но Дмитрий совершенно конкретно сформулировал что это за объект(таблица) - она содержит записи QR ярлыков, которые в новой схеме приложения становятся новыми полноправными членами. Прекрасно. при скане такого кода ты попадаешь на ВФ страницу которая не содежит инфорацию из записи QR ярлыка, а просто делает редирект на запись указанную в его лук-ап поле - т.е. на запись о книжке.

И тогда урл в QR коде должен быть такой Баз УРЛ+апекс\моя страница?id=айдизаписи Qr ярлыка

Вот я тоже так и думал - создать "промежуточный" объект, и все "перестановки" производить именно в нем.

Но Дмитрий совершенно конкретно сформулировал что это за объект(таблица) - она содержит записи QR ярлыков, которые в новой схеме приложения становятся новыми полноправными членами. Прекрасно. при скане такого кода ты попадаешь на ВФ страницу которая не содежит инфорацию из записи QR ярлыка, а просто делает редирект на запись указанную в его лук-ап поле - т.е. на запись о книжке. 

И тогда урл в QR коде должен быть такой Баз УРЛ+апекс\моя страница?id=айдизаписи Qr ярлыка

все верно :)

все верно :)