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

[lev]

посетила идея, но перед тем как её озвучить хочется задать уточняющий вопрос:
Вам известно на каком(каких) слое(ях) созданы объекты с префиксом, который надо удалить?

[mazzy]

Цитата:

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

посетила идея, но перед тем как её озвучить хочется задать уточняющий вопрос:
Вам известно на каком(каких) слое(ях) созданы объекты с префиксом, который надо удалить?

Да, конечно.
Полный ответ: в разных слоях, которые нам доступны.
Для простоты обсуждения можно считать: в одном слое.

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

[lev]

если это не системные слои, тогда предлагаю попытаться сделать по следующему алгоритму:

1. Делаем backUp приложения.
2. Заходим в аху формируем проекты для каждого слоя, где есть объекты для переименования (создаем проект, в нем нажимаем на "воронку". в выборе указываем для поля utilLevel критерий нашего слоя).
3. Экспортируем проекты нужных слоев с сохранением Id.
4. В полученных файлах выполняем переименование.
5. В приложении удаляем (переносим в другое место) слои, которые экспортировали.
6. Заходим в аху по очереди в каждый слой, начиная с более глубокого (например если экспортировали usr и cus, тогда в начале зайдем под cus) и заливаем наш проект.

В итоге должны получить то же приложение, но с нормальными названиями.

P.S. конечно же это теоретическая идея, не исключаю что на практике такое невозмжно

[mazzy]

Цитата:

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

если это не системные слои, тогда предлагаю попытаться сделать по следующему алгоритму:

3. Экспортируем проекты нужных слоев с сохранением Id.
4. В полученных файлах выполняем переименование.
5. В приложении удаляем (переносим в другое место) слои, которые экспортировали.
6. Заходим в аху по очереди в каждый слой, начиная с более глубокого (например если экспортировали usr и cus, тогда в начале зайдем под cus) и заливаем наш проект.

В итоге должны получить то же приложение, но с нормальными названиями.

Я так пробовал.
При УБИРАНИИ префиксов возникают дубли. Которые фиг отловишь в текстовом файле. Может быть какой нибудь EMacs поможет...

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

Цитата:

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

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

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

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

В общем, что делать с дублями при таком подходе?

[lev]

Цитата:

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

Я так пробовал.
При УБИРАНИИ префиксов возникают дубли. Которые фиг отловишь в текстовом файле. Может быть какой нибудь EMacs поможет...

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



В общем, что делать с дублями при таком подходе?

я так понял что вы просто выгружали проект, в нем переименовывали, а потом загружали обратно, рассчитывая что нужный объект переименуется и все будет ок. но он мало того что переименовывался, ещё и создавался второй, с таким же именем.

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

[sukhanchik]

Цитата:

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

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

Пример. Есть таблица (класс, тип и т.д.) LEV_InventTable (извините, что использую Ваш ник - просто мой слишком длинный). Убираю префикс. Что получается? Конфликт со штатным функционалом. При этом "хорошо", если LEV_InventTable было не таблицей. А если таблицей? А структура ее ну совсем отличается от InventTable?

Тоже думаю размышляю над веткой... Не приходит на ум "серебрянная пуля"

[lev]

Цитата:

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

Пример. Есть таблица (класс, тип и т.д.) LEV_InventTable (извините, что использую Ваш ник - просто мой слишком длинный). Убираю префикс. Что получается? Конфликт со штатным функционалом. При этом "хорошо", если LEV_InventTable было не таблицей. А если таблицей? А структура ее ну совсем отличается от InventTable?

Тоже думаю размышляю над веткой... Не приходит на ум "серебрянная пуля"

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

Вопрос к mazzy. А может у вас есть человек который напишет программку на каком нибудь Си языке (например C#) (ну или каком нибудь другом, без разницы ) которая произведет "правильное" переименование в файле?

[Андре]

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

[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

[sukhanchik]

Цитата:

Сообщение от Андре

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

Это уже проблема из другой области. Это можно перенести xpo-шник между приложениями/слоями (без сохранения id) и изменятся идентификаторы. Как раз если какие-то алгоритмы завязаны на id - они не пострадают при переименовании.
Эта проблема достаточно легко лечится - не нужно в клиентское приложение вливать свои хпо, а нужно обновлять приложение либо слоем (слоями), либо приложением. А если до часа Х переносили код хпошником - нужно просто забрать себе приложение/слои клиента, после чего уже хпошником не заливать

[mazzy]

Цитата:

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

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

Удалить - не получится.
Нужно сохранить уже имеющиеся данные.

Цитата:

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

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

[mazzy]

Цитата:

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

Вопрос к mazzy. А может у вас есть человек который напишет программку на каком нибудь Си языке (например C#) (ну или каком нибудь другом, без разницы ) которая произведет "правильное" переименование в файле?

Не проблема написать. На лиспе, на си-шарп... да хоть на X++.
КАК?

Я ж и спрашиваю про инструмент и/или методику

[mazzy]

Цитата:

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

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

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

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

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

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

[sukhanchik]

Цитата:

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

Удалить - не получится.
Нужно сохранить уже имеющиеся данные.

Удаление слоя при сохранении всех id никак не влияет на данные

[mazzy]

Цитата:

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

Удаление слоя при сохранении всех id никак не влияет на данные

как это? типа удалить и НЕ синхронизировать?

Можно пошагово?

[lev]

Цитата:

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

Удалить - не получится.
Нужно сохранить уже имеющиеся данные.

так разве при заходе в аксапту, синхранизация выполняется автоматически? мы же убиваем файл из приложения, таблицу в БД не трогаем! потом этот файл обратно заливаем, ИД таблицы сохраниться, данные потеряться не должны.

З.Ы. по поводу алгоритма "правильного" переименования думаю, если что придумается напишу

[lev]

Цитата:

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

Удаление слоя при сохранении всех id никак не влияет на данные

опередил

[lev]

Цитата:

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

как это? типа удалить и НЕ синхронизировать?

Можно пошагово?

написал выше

Цитата:

мы же убиваем файл из приложения, таблицу в БД не трогаем!
потом этот файл обратно заливаем, ИД таблицы сохраниться, данные потеряться не должны.

[sukhanchik]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

как это? типа удалить и НЕ синхронизировать?

Можно пошагово?

Легко.
1. Берем приложение. Экспортим с id в xpo слой.
2. Удаляем слой. Если не синхронизировать БД, то после запуска АОСа можно просто залить xpo обратно и все будет ок.
Если же мы переименовываем, то:
а) Надо подготовить приложение на пустой БД (залить туда xpo с id)
б) Надо убедиться в отсутствии в данных ссылок на название переименованного объекта
в) Надо пересоздать SQLDictionary на рабочем приложении (после копирования на рабочее приложение подготовленного). На эту тему почитать следующее:
Что нужно сделать: Изменение идентификаторов(id) полей или Изменение идентификаторов(id) полей

Имеющиеся потенциальные проблемы: Синхронизация

Полная инструкция по переносе объектов (таблиц) между слоями без сохранения ID, но без потери данных:
Перенос всех объектов с USR-слоя на VAR.