Распределенная разработка

[db]

вот пошаговая инструкция к глюку с old слоем
1. создаем edt type1
2. создаем таблицу table1 с полем field1 на основе типа type1
3. выходим из аксапты и копируем все aoi и aod в папку old
4. заходим заново и переименовываем type1 в type111
5. сравниваем table1 и old\table1 - как ни странно НИКАКИХ различий нет (должен быть другой EDT)
6. вспоминаеие все матные слова и забываете про папку old

[Maxim Gorbunov]

Цитата:

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

5. сравниваем table1 и old\table1 - как ни странно НИКАКИХ различий нет

И это правильно
Вспоминаем, что с точки зрения описания свойств поля таблицы внешним ключом является TypeId, а не имя типа. Соответственно, в свойствах таблицы никаких изменений не произошло: как было поле с типом 50005, например, так оно и осталось.

Для закрепления знаний сравним тип 50005 с его версией, сохраненной на old-слое (не забываем сбросить галочку suppress name property при сравнении). Убеждаемся, что имя для EDT - такое же свойство, как, например, и Alignment. Если Alignment у EDT поменялся, вы не увидите этого, сравнивая новую и старую версию таблицы. То же самое происходит и с именем.

В общем, про old-слои забывать не нужно. Надо ими правильно пользоваться.

[db]

Можно я пофлудю на пару страничек?

Максим, Вы всерьез верите в то, что написали?
Очень похоже на стиль отписок из техподдержки майкрософта. Вы там случайно не работаете
Типа все работает by design, а то что design кривой то это не наши проблемы

Как понимание того, что ключ изменился или не изменился поможет человеку в реальной работе по подъему
кода? Логично предположить, что человек, занимающийся сравнением кода между слоями
хочет видеть все изменения, которые произошли и не видеть того, чего на самом деле нет.
И изменился там ключ, не изменился в данном случае
не должно играть никакой роли. Ибо использование ид в качестве общего ключа двух РАЗНЫХ приложений
выглядит несколько странным.
Если система врет (а она врет), предоставляя
неверные данные, то каков будет результат работы, основанный на таких данных?

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

Если у меня в старом приложении У таблицы table1 поле field1 имело тип type1
а в новом это же поле имеет type2 в результатах сравнения я хочу это видеть.
И не чесать репу, почему это вдруг показывается что в старом приложении поле не имело никакого EDT
(так показывается, если в новом приложении edt c ид от type1 нет)
И не чесать репу, думая что за идиот сменил у поля edt type1 на mysupertype (так показывается, если в новом приложении
mysupertype имеет тот же ид, что был у type1 в старом)
...
Список возможных вариантов можно легко продолжить

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

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

Основных проблем здесь две
1. элементы с одним ид в разных приложениях считаются одним и тем-же (ну это скорее проблема дизайна)
2. при вытаскивании свойств элементов старого приложения, являющихся ссылками на другие элементы с собственным ид, поиск имени этого элемента, возвращаемого в AotGetProperties идет почему то не в старом, а в новом приложении (а вот это уже 100% баг). И никакая галочка "Подавлять свойства" здесь не спасет.

Ваш пример со сравненеим переименованного типа как раз работает правильно (если не учитывать проблему 1),
и даже выдает различие имен, но проблема не со сравнением EDT нового и старого, а со сравненеием старый/новый
другого элемента, ссылающегося на этот EDT

Всем удачных праздников, а мне очердного удачного запуска
Чего только со скуки не напишешь