Баг или не баг?

[S.Kuskov]

Цитата:

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

А если есть - то как быть?

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

Почему так делать опасно уже здесь написали, но видимо недостаточно убедительно

[sukhanchik]

Цитата:

Сообщение от S.Kuskov

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

Почему так делать опасно уже здесь написали, но видимо недостаточно убедительно

Ааа.... возможно я не так понял. Тогда да, апгрейд-скрипты конечно не нужны и проблемы только в коде. Хотя останется 2 проблемы:
1. Ситуация со знаками > и < (я про это писал) при сравнении значений енумов
2. Ситуация, когда вместо перечисления конкретных значений енума - указывается отрицание оставшихся значений. Ну, к примеру, можно написать:

switch (x)
{
      case 1,2,3:
..................
      default: 
}

А можно написать так:

if (x !=4)

Но это все проблемы именно анализа кода, а не данных.
Предопределенные данные могут возникать тогда, когда эти данные выпускает сам МС. Например, шаблоны отчетов для генератора финотчетности (ГФО). Тут конечно нельзя так просто отбросить именно МС-овские енумы.

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

Так что если не смотреть вперед на обновление версий - то, в общем-то вариант, когда при конфликте значений берется значение не от МС - вполне жизнеспособен.

[S.Kuskov]

Цитата:

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

2. Ситуация, когда вместо перечисления конкретных значений енума - указывается отрицание оставшихся значений.

Эмм... не понял вас. Я вижу проблему при любом использовании числового значения элемента перечисления вместо его имени.

[sukhanchik]

Цитата:

Сообщение от S.Kuskov

Эмм... не понял вас. Я вижу проблему при любом использовании числового значения элемента перечисления вместо его имени.

Не... я тут имел в виду общую проблему, которая в принципе возникает при любом добавлении нового элемента енума. Это не относится к числовому представлению.

Пример (АХ 2009):
Тип партнера договора (RContractPartnerType). Штатно этот енум имеет 2 значения: Клиент и Поставщик (будем считать, что у нас нет слоя с зарплатой, где еще добавляется сотрудник).
В коде, который относится к обработке клиентских договоров можно встретить 2 варианта:
1.

if (rcontractTable.RContractPartnerType == RContractPartnerType::Cust)

и
2.

if (rcontractTable.RContractPartnerType != RContractPartnerType::Vend)

как вариант вот так:

if (rcontractTable.RContractPartnerType == RContractPartnerType::Cust)
{
}
else
{
}

Теперь представим себе, что мы добавляем новое значение в енум RContractPartnerType.

В зависимости от предназначения этого нового элемента - вышеуказанные конструкции нам придется подправить или возможно вообще видоизменить (например, if ... else преобразовать в switch)

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

[Murlin]

Цитата:

Сообщение от S.Kuskov

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

Почему так делать опасно уже здесь написали, но видимо недостаточно убедительно

что именно опасного? т.е. действительно "опасного" а не то что вы с формы не перейдете на другую форму. relation - да
код вида
inventTrans.TransType > a и inventTrans.TransType < b
по большим сомнением... Т.к. выпуская sp с новым enumом
я думаю в нем будет исправление
inventTrans.transtype>a и inventTrans.TransType<c

[dech]

Цитата:

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

что именно опасного? т.е. действительно "опасного" а не то что вы с формы не перейдете на другую форму. relation - да
код вида
inventTrans.TransType > a и inventTrans.TransType < b
по большим сомнением... Т.к. выпуская sp с новым enumом
я думаю в нем будет исправление
inventTrans.transtype>a и inventTrans.TransType<c

Скорее всего вы не найдёте в системе таких енумов, где значение b является последним, а уж тем более, где между a и b есть разрыв. Обновление таких енумов не затрёт старые значения, а только лишь дополнит. Так что такой код ошибку не вызовет, хоть он и написан не очень корректно. Кстати, мне встречался такой код, где был добавлен новый элемент в енум, причем в коде забыли прописать подобную строку:

inventTrans.transtype>a && inventTrans.TransType<c

Приходилось самому исправлять.