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

[sukhanchik]

Цитата:

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

Используйте value2Symbol. Ведь вы по значению хотите определять. А то что index2Symbol не работает для такого случая, это вполне логично ведь 100 элемента нет, есть значение 100.

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

Что же касается апгрейд-скриптов - то речь идет о следующей ситуации:
имеем АХ сервис-пак N. В этом приложении имеется енум со значениями 1,2,3,4.
Выпускается сервис-пак N+1. В нем Микрософт добавил новое значение, допустим 5.
Но Вы в своей модификации тоже добавили значение 5. Возникает конфликт - т.к. в БД хранится число 5 и БД заведомо не знает - это 5 для функционала от Микрософта или 5 для функционала Вашего. Требуется выполнение некоторых действий (=написание апгрейд скриптов), которые "разведут" в Вашей БД число 5 от Микрософта и число 5 от Вашей модификации.

Поэтому было принято негласное соглашение. Микрософт добавляет номера енумов по порядку (1,2,3,4,5), а партнеры / клиенты - делают некоторый резерв по номерам и начинают нумеровать с 32-го, 100-го или еще какого-то большого номера.

К сожалению, в 2012-й эта практика была нарушена и уже внутри Микрософта появились вот такие вот "дырки" вида 1,2,3,4,100. Тем не менее - использование номеров енума не по порядку - есть нормальное явление, а номера енумов прописываются как было верно подмечено в БД и релейшнах. А местами еще (к сожалению) используются знаки сравнения "больше" и "меньше" применительно к значениям енумов.