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

[dech]

Цитата:

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

Ok. Предположим я использовал 5 для связки со своими какими то записями, вышло обновление где enum назначена цифра 5, но это новая сущность новое понятие, новые записи. Какой смысл заносить его со старым значением 5. Зачем залазить в blob, rls и сохраненные запросы, если никаких настроек на эту сущность еще в принципе не существовало. Единственный минус тут в том что код a.b > c::a && a.b < c::d работать не будет. (По мойму вот это
a.b > c::a && a.b < c::d нужно сделать антиBP.)
Я вот не могу понять...

При обновлении енуму не назначается цифра 5, а в этот енум добавляется элемент со значением 5, меткой и еще парой свойств. Правило гласит, что элементы не могут иметь одинаковые значения. Но иметь разрывы нумерации элементов - вполне допустимо. И этим пользуются. Что тут непонятного?

[Murlin]

Цитата:

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

При обновлении енуму не назначается цифра 5, а в этот енум добавляется элемент со значением 5, меткой и еще парой свойств. Правило гласит, что элементы не могут иметь одинаковые значения. Но иметь разрывы нумерации элементов - вполне допустимо. И этим пользуются. Что тут непонятного?

При сравнении слоев создавать элемент с таким же именем но другой цифрой, той же меткой и такими же свойствами но с цифрой 6 на usr слое, никаких апгрейд скриптов не нужно. Не существуют записи или сохраненные запросы с таким значением в этом поле соответствующем enum'у, если c SP пришло новое значение enum'а которого до этого на нижних слоях не было. Значения enum'а не несут никакого смысла.

[db]

Ок, пусть с 5 останется ваш элемент, новый вы вместо 5 переделаете в 6. что имеем
1). Надо пойти и найти все новые релейшены и там то же исправить 5 на 6, причем старые релейшены оставить 5. Это повторять при каждом СП
2). Как уже говорили диапазоны енумов могут начать работать некорректно
3). Некоторые внешние программы/сервисы/партнерские решения напрямую лазяющие в бд видя цифру 5 будут думать что это новое значение из сервиспака а не ваше творчество. У вас с большой вероятностью доступа к их исходному коду не будет
4) Пришедшие после вас/просто коллеги будут три дня охреневать с матюгами какого всё это так сделано. Документирование подобных извращений не спасет ни от матюгов ни от вопросов

В итоге мозг вы взорвете и себе и свои коллегам/последователям на ровном месте, попутно подставив своего работодателя на дополнительные затраты по поддержке хитровывернутых замыслов

Если в стандарте ошибка, то надо ее зарегистрировать в мс и/или исправить самим. Как уже неоднократно писали дырки в енумах это абсолютно нормально. То что и в стандарте кое где про это забыли - ну такова жизнь, что еще сказать