Префиксы-суффиксы. Какой инструмент лучше использовать чтобы избавиться от префиксов?

[Владимир Максимов]

Цитата:

Сообщение от mazzy

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

В подобных случаях, думаю, логичнее префикс превратить в суффикс. Кроме того, как уже упоминалось, если имена совпадают - это повод пересмотреть логику использования объектов. Думаю, можно сделать такой сценарий:

1. Если удаление префикса не приводит к дублированию имен, то удаляем префикс
2. Если удаление префикса приводит к дублированию имен, то
2.1. Переносим префикс в конец имени делая из него суффикс
2.2. Сообщаем пользователю о возникшей коллизии, чтобы он пересмотре логику использования данного объекта

============================

Вообще-то, насколько я понимаю, в самом общем виде задача ставится так:

как переименовать объект, чтобы все ссылки на него также переименовались.

Как мне кажется, в общем случае, полностью автоматическими средствами этого не сделать. Далеко не все ссылки на объект можно изменить автоматически. Например, в коде метода. Т.е., в общем случае, часть ссылок будет переименована автоматически, но останется некая часть, которую придется выискивать и переименовывать вручную. Вопрос только в пропорциях.

Лично я сделал бы следующее:

1) Перекрестные ссылки. Где используется объект.
2) Поиск по тексту внутри методов на случай, например, прямых SQL-запросов к серверу или обращение через _args.caller()
3) Дополнительный Job для поиска по свойствам, которые не учитываются в перекрестных ссылках и не могут быть найдены по тексту метода или средствами стандартного поиска (не знаю, FormRef, например, стандартный поиск найдет?)

Фиксирую все найденные места использования. Переименовываю объект и повторяю цикл для нового имени. Далее сравниваю полученные списки использования и вручную корректирую те места, где "автомат" не справился.

==========================

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

[mazzy]

Цитата:

Сообщение от Владимир Максимов

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

можно и так

Цитата:

Сообщение от Владимир Максимов

Вообще-то, насколько я понимаю, в самом общем виде задача ставится так:

как переименовать объект, чтобы все ссылки на него также переименовались.

ага.

Цитата:

Сообщение от Владимир Максимов

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

про код - понятно.
у меня конечно были надежды на синтаксическое переименование... но что-то мне совсем не понравилось как оно работает. может чего не понимаю.

Цитата:

Сообщение от Владимир Максимов

Т.е., в общем случае, часть ссылок будет переименована автоматически, но останется некая часть, которую придется выискивать и переименовывать вручную. Вопрос только в пропорциях.

Ага.

Цитата:

Сообщение от Владимир Максимов

Лично я сделал бы следующее:

1) Перекрестные ссылки. Где используется объект.
2) Поиск по тексту внутри методов на случай, например, прямых SQL-запросов к серверу или обращение через _args.caller()
3) Дополнительный Job для поиска по свойствам, которые не учитываются в перекрестных ссылках и не могут быть найдены по тексту метода или средствами стандартного поиска (не знаю, FormRef, например, стандартный поиск найдет?)

Перекрестные ссылки - найдут.
Поиск - только расширенный по свойствам, а не по методам.

Цитата:

Сообщение от Владимир Максимов

Фиксирую все найденные места использования.

Вручную?!

Цитата:

Сообщение от Владимир Максимов

Переименовываю объект и повторяю цикл для нового имени. Далее...

Т.е. рекомендуешь итерационный подход? когда имена меняются один за другим.
В принципе я склоняюсь к этому же.

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

Цитата:

Сообщение от Владимир Максимов

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

Э-э-э... Не одна Аксапта, не одна. Она даже не центр вселенной.
Она всего лишь одна из баз. Связанная с кучей сервисов.

[Владимир Максимов]

Цитата:

Сообщение от Владимир Максимов

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

Цитата:

Сообщение от mazzy

Э-э-э... Не одна Аксапта, не одна. Она даже не центр вселенной.
Она всего лишь одна из баз. Связанная с кучей сервисов.

Хм... Но ведь если ты будешь переименовывать объекты Axapta, то другие сервисы все-равно должны измениться. Под эти новые имена. И какая разница, останутся ли в Axapta старые имена или нет?

[sukhanchik]

Вообще-то я больше склоняюсь к мысли Владимира Максимова:

Цитата:

Сообщение от Владимир Максимов

1) Перекрестные ссылки. Где используется объект.
2) Поиск по тексту внутри методов на случай, например, прямых SQL-запросов к серверу или обращение через _args.caller()
3) Дополнительный Job для поиска по свойствам, которые не учитываются в перекрестных ссылках и не могут быть найдены по тексту метода или средствами стандартного поиска (не знаю, FormRef, например, стандартный поиск найдет?)

Единственное - не очень понятный п.3 из его алгоритма. FormRef ссылается на пункт меню, а в отличие от тех же классов - названия пунктов меню хранятся текстом - т.е. надо будет ручками (кодом) менять название во всех местах. А перекрестные ссылки, начиная с 4.0 вроде как уже дают полную информацию, включая пункты меню.
В п.2 конечно неплохо добавить еще использование [Sys]Dict* классов и вариантов тупого прописывания названия объектов в коде обычным текстом.

Еще есть момент. Была у меня таблица DEV_SuperTable. Хочу ее переименовать в (к примеру) LedgerSuperTable. Очевидно, что я должен переименовать попутно:
1. Форму DEV_SuperTable (если есть). Необязательно, но по-хорошему - я должен переименовать все датасорсы (помимо исправления ссылок), чтобы на таблицу LedgerSuperTable не указывал датасорс DEV_SuperTable. Это потянет изменение в коде ссылок на этот датасорс.
2. Пункт меню DEV_SuperTable (если есть, причем - если я его не переименую - у меня могут быть проблемы при переходе к основной таблице). В самом пункте меню еще нужно изменить ссылку на форму
3. Теперь надо не забыть про сложные составные имена. Типа DEV_SuperPuperTable и DEV_SuperNotPuperTable. А также про DEV_LedgerSuperTable. Надо решить - как их нужно будет переименовывать

Надеюсь - названия таблиц/полей не используются в хранимых процедурах, ОЛАП-кубах/отчетах, Reporting Services и прочих сторонних системах (кстати - ужас - на что толкает нас МС - отказ от использования перекрестных ссылок - т.к. внешние использования таблиц/полей, а теперь еще и Query в Visual Studio - естественно не будут учтены перекрестными ссылками)

Поэтому - я наверное склоняюсь к правилу 20/80. Т.е. переименовать 80% объектов за 20% усилий. Просто пойти по перекрестным ссылкам. Если объект можно переименовать (проверяется возможность создания объекта в АОТ с таким именем) - то согласно перекрестным ссылкам переименовать объект и ссылки на него. Без заморочек с датасорсами и сложными названиями.
Дальше вывести - список - чего осталось. Оценить масштабы бедствия. Что-то действительно руками (возможно) быстрее сделать.
Масштабы бедствия не должны быть большими - иначе бы функциональность перекрестных ссылок была бы не показательна.
Также вряд ли будет много пересечений со штатным функционалом. Обычно пересечения могут быть на наиболее используемых таблицах типа InventTable, Может даже InventTrans. Но вряд ли напишут "свой" класс с названием типа AddressEngineKernelInternational_RU.

Еще можно датасорсы переименовать. Но это уже следует делать вторым проходом - когда уже переименованы сами объекты. Тут нужно не забыть "прошерстить" все контролы на форме и все обращения типа DEV_SuperTable_ds, DEV_SuperTable_q, DEV_SuperTable_qr

[mazzy]

Цитата:

Сообщение от sukhanchik

Еще есть момент. Была у меня таблица DEV_SuperTable. Хочу ее переименовать в (к примеру) LedgerSuperTable. Очевидно, что я должен переименовать попутно:
1. Форму DEV_SuperTable (если есть). ....
2. Пункт меню DEV_SuperTable ...
3. Теперь надо не забыть про сложные составные имена. Типа DEV_SuperPuperTable и DEV_SuperNotPuperTable. ...

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

Как выполнить переименование?

Хотя... Щас писал и подумал... А ведь если у нас есть таблица соответствий, то в ней можно и дубли отследить. ДО переименования. А затем выполнить замену в текстовом файле...

Мысль интересная.

[sukhanchik]

Цитата:

Сообщение от mazzy

А ведь если у нас есть таблица соответствий, то в ней можно и дубли отследить. ДО переименования. А затем выполнить замену в текстовом файле...

Ээээ а ведь так и штатный апгрейд 3.0 -> 4.0 по выравниванию полей проходил. Т.е. составлялся список полей к выравниванию, после чего производилось выравнивание.

[gl00mie]

Цитата:

Сообщение от mazzy

Не проблема написать. На лиспе, на си-шарп... да хоть на X++. КАК? Я ж и спрашиваю про инструмент и/или методику

Снова хочется вспомнить статью Джоэла Спольски "Где грязь, там и деньги" (цитировалась тут). Нет у этой сложной задачи простого и ясного решения - нужно повозиться, найти все "частные случаи" - тогда, может, появится полуэвристическая методика, которая, впрочем, не факт что будет работать на 100% в других условиях. За эту "возню в грязи" клиент и платит деньги хотя если по результатам родится некий инструмент, облегчающий решение таких задач, то будет здорово.

Цитата:

Сообщение от sukhanchik

Поэтому - я наверное склоняюсь к правилу 20/80. Т.е. переименовать 80% объектов за 20% усилий. Просто пойти по перекрестным ссылкам. Дальше вывести - список - чего осталось. Что-то действительно руками (возможно) быстрее сделать.

Полностью поддерживаю.

Цитата:

Сообщение от lev

так разве при заходе в аксапту, синхранизация выполняется автоматически

Часть таблиц - синхронизируется автоматически, см. \Classes\Application\syncApplTables, вызываемый в \Classes\Application\new. А еще вроде таблицы синхронизируются перед сравнением, вызываемым из формы импорта проектов.

Цитата:

Сообщение от mazzy

Хотя... Щас писал и подумал... А ведь если у нас есть таблица соответствий, то в ней можно и дубли отследить. ДО переименования. А затем выполнить замену в текстовом файле...

Замена в текстовом файле - штука небезопасная, потому что одно имя может оказаться подстрокой другого, т.е. как минимум нужно переименовывать в режиме поиска слова целиком или использовать регулярные выражения, и все равно может оказаться, что переименование безопасно проводить лишь в определенной последовательности, а не произвольно. Это схоже с проблемами скриптов обновления данных при переходе на новый SP/версию - в руководстве по их написанию акцентируют внимание на требовании к т.н. идемотентности.

PS. Вспоминаются давнишние рассуждения касаемо дефрагментации RecId (в частности, эти) - мне кажется, между этими задачами, если не вдаваться в технические детали, довольно много общего...

[mazzy]

Цитата:

Сообщение от gl00mie

Снова хочется вспомнить статью Джоэла Спольски "Где грязь, там и деньги" (цитировалась тут). Нет у этой сложной задачи простого и ясного решения - нужно повозиться, найти все "частные случаи" - тогда, может, появится полуэвристическая методика, которая, впрочем, не факт что будет работать на 100% в других условиях. За эту "возню в грязи" клиент и платит деньги хотя если по результатам родится некий инструмент, облегчающий решение таких задач, то будет здорово.Полностью поддерживаю.

Платит-платит.
И давай не будем путать сложные задачи с нерешаемыми задачами.
То, что задача сложная - вовсе не означает, что с ней надо возится бессистемно.

Вернемся таки к методике.
Похоже она таки есть. И сводится к замене в текстовом XPO-файле.

Предлагаю на обсуждение черновой вариант:
0. Подготовительная фаза
0.1. выгружаем строки из формы Пути к объектам в Excel-таблицу (со слоями)
0.2. отделяем пути от названия объектов
0.3. в Excel копируем названия объектов во вторую колонку
0.4. [опционально] оставляем только строчки с названиями объектов, которые могут быть переименованы (изо всех слоев, все названия). Например, оставляем (названия форм, датасорсов, методов), названия (таблиц, полей, групп, индексов), названия menuItem и т.п. Убираем label, documentation, контролы внутри форм, элементы внутри enum и т.п.
1. план переименования
1.1. во второй колонке Excel проводим черновое переименование объектов
1.2. во второй колонке Excel формулой находим возможные (с учетом путей) конфликты, дубликаты
1.3. разрешаем конфликты, вводя суфиксы или сохраняя префиксы
1.4. повторяем 1.1-1.4 пока не будут разрешены все конфликты переименования
1.5. в результате получили план переименования: в большинстве объектов префиксы будут удалены, но в некоторых объектах названия изменятся более сложным образом
2. Исполнительная фаза (воможен алгоритм от lev)
2.1. выгружаем слой в XPO
2.2. переименовываем согласно плана переименования (переименовываются как свойства, так и строки кода). Можно выполнять как вручную, так и с помощью каких-нибудь интеллектуальных макросов (типа Emacs). Можно и программку написать
2.3. загружаем измененный XPO
2.4. если во время загрузки получаем конфликты, возвращаемся на шаг 1.1.
3. Проверка
3.1. проводим глобальную компиляцию с уровнем детализации = 4 и со включением заранее выбранного набора рекомендаций.
3.2. если компиляция выдала ошибки и/или рекомендации - разбираемся с ними (возможно возвращаясь на шаг 1.1)

примерно так.
т.е. все-таки работаем с текстовым XPO.
но не механически, а на основании заранее подготовленного плана.

инструменты:
= excel
= xpo
= какой-нибудь продвинутый текстовый редактор, который умеет делать массовую замену по плану (текстовый файл)

[gl00mie]

Цитата:

Сообщение от mazzy

выгружаем строки из формы Пути к объектам в Excel-таблицу (со слоями)

Хм, речь ведь о xRefPaths?.. к слову, я себе для облегчения перехода на новые SP/версии приделал показ самого верхнего слоя в xRefPaths, чтобы можно было отделить ссылки, ведущие к модификациям, от стандартного приложения, щас выложу... А еще можно подцепить xRefNames и взять оттуда для каждого уникального имени идентификатор, тип, название родительского объекта...

Цитата:

Сообщение от mazzy

0.2. отделяем пути от названия объектов
0.3. в Excel копируем названия объектов во вторую колонку
0.4. [опционально] оставляем только строчки с названиями объектов, которые могут быть переименованы (изо всех слоев, все названия). Например, оставляем (названия форм, датасорсов, методов), названия (таблиц, полей, групп, индексов), названия menuItem и т.п.

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

Цитата:

Сообщение от mazzy

2. Исполнительная фаза
2.1. выгружаем слой в XPO
2.2. переименовываем согласно плана переименования (переименовываются как свойства, так и строки кода). Можно выполнять как вручную, так и с помощью каких-нибудь интеллектуальных макросов (типа Emacs). Можно и программку написать

Вот тут, мне кажется, и начнется самое интересное... Я бы все же при переименовании попытался использовать информацию из перекрестных ссылок, как это делает "Синтаксическое переименование", - так по усилиям/результату получится ближе к озвученному уже закону Парето. Переименование без семантической информации все же чревато: как вы, к примеру, отделите переименование поля XYZ_Name в Name от переименования метода XYZ_Name() в name_RNR() (при условии, что для метода возник конфликт имен, и решили сделать суффикс)?
У меня лично был такой "опыт" простого текстового переименования. 3-ка, как выяснилось, допускает использование в именах объектов приложения (как минимум методов) ту же кириллицу. Такой код прекрасно работает, пока не начинаешь пытаться запустить его на 2009-й - та резонно ругается при компиляции на чужеродные символы, а когда их заменяешь, начинает ругаться на код, в котором остались ссылки на названия с кириллицей. Одному разработчику это надоело, и он прошелся поиском-и-заменой, перебив в существенной части кода русскую строчную "с" на латинскую заглавную "C" (а, может, забыл включить учет регистра), в результате чего код-то изменился, но изменились также обширные написанные на русском комментарии, которые стали выглядеть м... "страшненько"

[BOAL]

Когда-то делал такое, но без такой мегасистемы. Возможно, так на так и выйдет по времени.
Тк предпочитаю "чувствовать" код, а для этого его нужно читать и ручками холить и лееять.
Итого алгоритм свелся к
1. выгрузить все в ХРО
2. Нотпад+ с УТФ поддержкой - Ктрл-R с не "заменить все", а с поштучной заменой, а то может найти не то по вхождениям. При этом шаг с ехелей и что на что - на бумажке или в голове
3. закачать все обратно - если там Глобал, Инфо и Апликатионс с Класс фактори не убиты, то проблем нет
4. Глоб компил и далее ходим и правим, че отвалилось (тут нужно иметь свой набор полезных тулов, тк на стандарте одни переходы через второй уровень поп-ап меню по ПКМ заколебет)

На большом слое (ХРО за 60мб) такая процедура заминаем 1-2 дня одного человека (с опытом подъема на слои, у которого реальный норматив 10-15мин на элемент в среднем)
Может даже и меньше занять по времени, но потом с чувством выполненного долга этот чел будет пинать балду, тк нервное напряжение сил и внимательность к мелочам утомляют.
А обсуждать это дольше чем делать.... как-то не практично
Но да, "семь раз отмерь - один раз закодь" - только у нас же не кирпичи, нам стену потом не ломать, что б на 50см сдвинуть, это все же строчки текста (хотя по времени равносильно может быть и по усталости исполнителя, но расходники не тратятся впустую).

Касательно ХРО - пока он в текстовом файле, а от версии к версии сравнение АХ все хромает и хромает (когда ж элементы формы будут стрелками тягаться со свойствами и прочие прелести), то я лично пришел к тому, что для переноса ах4-фх2009 было пользительно пользовать вообще сравнение текстовых файлов (кодерские тулзы с подстветкой синтаксиса) - так можно кликами (или Алт + стрелочки) тягать код и свойства.
Не всегда это быстрее сравнилки АХ, но по некоторым элементам дает прирост во времени в разы.
Опять же не восстанавливать форму (а по сути кодя ее с нуля), а именно объединять код было-стало.

[mazzy]

Цитата:

Сообщение от sukhanchik

Выгружаем в XPO конечно с сохранением id ?

Да, конечно.
про удаление, (не) синхронизацию и шаманство с базой - понял. Да

Цитата:

Сообщение от sukhanchik

Т.е. в этом случае никаких прыжков с удалением/восстановлением SQLDictionary делать не придется

Тоже понял. Но тут нужны будут эксперименты.

Цитата:

Сообщение от gl00mie

Хм, речь ведь о xRefPaths?..

Ага.
Подумав хорошенько понял, что, в принципе, можно выгрузить и любым другим образом. Например, программно пробегаясь по дереву AOT при помощи TreeNode.
Поэтому способ получения списка остается на усмотрение исполнителя-программиста. Как ему удобнее, пусть так и получает.

Главное - получить полный список объектов, которые могут влиять на переименование.

Цитата:

Сообщение от gl00mie

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

Я написал "опционально" поскольку это на усмотрение исполнителя. Вдруг ему будет удобнее работать с неочищенным списком.

Цитата:

Сообщение от gl00mie

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

А как это делает "Синтаксическое переименование"?

Цитата:

Сообщение от BOAL

При этом шаг с ехелей и что на что - на бумажке или в голове

Не, "в голове" не надо.
В том то и дело, что хочется найти методику, которая позволяет:
= распределить работу между несколькими людьми
= проконтролировать процесс исполнения
= убедиться что выполнено все (ничего не забыто)

Цитата:

Сообщение от BOAL

На большом слое (ХРО за 60мб) такая процедура заминаем 1-2 дня одного человека (с опытом подъема на слои, у которого реальный норматив 10-15мин на элемент в среднем)

Спасибо. Оценку понял.

Цитата:

Сообщение от BOAL

(когда ж элементы формы будут стрелками тягаться со свойствами и прочие прелести)

тягаются. alt+стрелки.