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

[Murlin]

Цитата:

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

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

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

Допустим при переносе SP я вместо майкрософтовского 5 сделаю 6... Подниму на Usr слой с этим значением, после этого останется поправить только новые relationы(тем более что relation даже визуально проще найти ошибку)
Какие апгрейд скрипты, какие запросы какие RLS. Передается именно значение

[sukhanchik]

Цитата:

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

Допустим при переносе SP я вместо майкрософтовского 5 сделаю 6... Подниму на Usr слой с этим значением, после этого останется поправить только новые relationы(тем более что relation даже визуально проще найти ошибку)
Какие апгрейд скрипты, какие запросы какие RLS. Передается именно значение

Вы сейчас рассуждаете только с одной стороны - со стороны программного кода.
Ну вот был у Вас SP N, Вы подготовили приложение (переделали все relation-ы) с SP N+1 (заменили все 5 на 6 и т.д.).
А теперь Вам надо обновить рабочую (!) БД. И очевидно, что в процессе обновления люди работать в рабочей системе не смогут. Вопрос: сколько по времени может длиться Ваше обновление? А если система работает в режиме 24х7? Если нет - то ночью могут запускаться какие-то тяжелые процессы каких-нибудь расчетов / пересчетов. И дело тут не в отдельно взятых енумах. Базу не начинают с нуля при обновлении сервис-пака.
Чтобы грамотно все обновить - нужно составить список таблиц и полей в них - где это значение (5) могло бы использоваться, чтобы его там перебить на новое значение (6).

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

А как уже было сказано - эти места могут быть и завуалированы (например, в BLOB-поле, в котором хранится запакованный Query),

Т.е. еще раз повторюсь - проблема не столько в программном коде, который выгружается в XPO - сколько в обновлении данных и сокращении времени простоя рабочей БД.

[Murlin]

Цитата:

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

Вы сейчас рассуждаете только с одной стороны - со стороны программного кода.
Ну вот был у Вас SP N, Вы подготовили приложение (переделали все relation-ы) с SP N+1 (заменили все 5 на 6 и т.д.).
простоя рабочей БД.

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

[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) Пришедшие после вас/просто коллеги будут три дня охреневать с матюгами какого всё это так сделано. Документирование подобных извращений не спасет ни от матюгов ни от вопросов

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

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

[S.Kuskov]

Цитата:

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

Допустим при переносе SP я вместо майкрософтовского 5 сделаю 6...

Обычно в случае конфликта системного кода и собственного меняют собственный, а не наоборот. Можно конечно и системный переопределить но ... остлеживание коллизий при каждом следующем обновлений, несовместимость с другими модификациями ...

Цитата:

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

при восстановлении очень старой БД(бэкапа) мне нужно будет что то с ней делать..

Востанавливать на очень старую версию приложения.

[Murlin]

Цитата:

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

Обычно в случае конфликта системного кода и собственного меняют собственный, а не наоборот. Можно конечно и системный переопределить но ... остлеживание коллизий при каждом следующем обновлений, несовместимость с другими модификациями ...


Востанавливать на очень старую версию приложения.

А отслеживать вызовы index2Symbol??? Не тоже ли самое, не тяжелее. Код я не меняю я меняю только значение enum. Значение enum по мойму вообще не несет никакого смысла абсолютно