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

[SRF]

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

[Murlin]

Цитата:

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

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

index2Symbol используется в системе(gls слой).. например на форме заполенения подписей в складских журналах. Править код gls?

[SRF]

Цитата:

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

Править код gls?

Вообще да, а что это делать запрещено? Не ошибается тот, кто ничего не делает.
И в 2012 в методах определения должностных лиц по складским журналам используется index2Symbol, тоже приходилось править.

Класс InventJournalPrintForm_RU метод run, в 2х местах (это dax2012)

...
        //dsName = dictEnum.index2Symbol(report.reportType());
        dsName = dictEnum.value2Symbol(report.reportType());
...

[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. Тем не менее - использование номеров енума не по порядку - есть нормальное явление, а номера енумов прописываются как было верно подмечено в БД и релейшнах. А местами еще (к сожалению) используются знаки сравнения "больше" и "меньше" применительно к значениям енумов.

[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'а не несут никакого смысла.

[S.Kuskov]

Цитата:

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

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

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

Цитата:

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

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

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

[Murlin]

Цитата:

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

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


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

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

[Murlin]

Цитата:

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

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

Так значит я выбрал 100 но 100 у меня уже где то используется в новом SP и поэтому при восстановлении очень старой БД(бэкапа) мне нужно будет что то с ней делать...
Выигрыша никакого не вижу совсем.
Но с другой стороны код вида, select a where a.b<C: && a.b>C::B
Работать не будет, но и зачем такой код нужен, по мойму и так и так будет скан таблицы, и с перечислением и без.
Зачем майкрософт пишет такой код?