![]() |
#22 |
Роман Долгополов (RDOL)
|
Можно я пофлудю на пару страничек?
Максим, Вы всерьез верите в то, что написали? Очень похоже на стиль отписок из техподдержки майкрософта. Вы там случайно не работаете ![]() Типа все работает by design, а то что design кривой то это не наши проблемы ![]() Как понимание того, что ключ изменился или не изменился поможет человеку в реальной работе по подъему кода? Логично предположить, что человек, занимающийся сравнением кода между слоями хочет видеть все изменения, которые произошли и не видеть того, чего на самом деле нет. И изменился там ключ, не изменился в данном случае не должно играть никакой роли. Ибо использование ид в качестве общего ключа двух РАЗНЫХ приложений выглядит несколько странным. Если система врет (а она врет), предоставляя неверные данные, то каков будет результат работы, основанный на таких данных? Настоящее веселье начинается не при переименовании элементов, а при совпадении ид у разных элементов (отличающихся не только именами) между старым и новым приложением. Если у меня в старом приложении У таблицы table1 поле field1 имело тип type1 а в новом это же поле имеет type2 в результатах сравнения я хочу это видеть. И не чесать репу, почему это вдруг показывается что в старом приложении поле не имело никакого EDT (так показывается, если в новом приложении edt c ид от type1 нет) И не чесать репу, думая что за идиот сменил у поля edt type1 на mysupertype (так показывается, если в новом приложении mysupertype имеет тот же ид, что был у type1 в старом) ... Список возможных вариантов можно легко продолжить При подъеме кода уже через час работы сидишь как обкуренный и дополнительная мыслительная деятельность здесь явно ни к чему. Скажете это все редкие случаи? И если иногда будет криво, то и пусть? Если так, то это очень похоже, например, на работу циркуляркой с треснутым диском. Авось отпилим. Только все время будет ожидание, что пила вот вот развалится. Будем ее проверять, рассматривать и молиться что не получим куском пилы в лоб ![]() Основных проблем здесь две 1. элементы с одним ид в разных приложениях считаются одним и тем-же (ну это скорее проблема дизайна) 2. при вытаскивании свойств элементов старого приложения, являющихся ссылками на другие элементы с собственным ид, поиск имени этого элемента, возвращаемого в AotGetProperties идет почему то не в старом, а в новом приложении (а вот это уже 100% баг). И никакая галочка "Подавлять свойства" здесь не спасет. Ваш пример со сравненеим переименованного типа как раз работает правильно (если не учитывать проблему 1), и даже выдает различие имен, но проблема не со сравнением EDT нового и старого, а со сравненеием старый/новый другого элемента, ссылающегося на этот EDT Всем удачных праздников, а мне очердного удачного запуска Чего только со скуки не напишешь ![]() |
|