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

[Murlin]

ax 2009 метод dictEnum.index2Symbol не работает если какому то значение enum назначить значение в разрыв. т.е. было 1,2,3,4 добавили новое со значением 100. Метод перестает работать и выдает что то по китайски.

[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());
...

[dech]

Кажется в Колумбусе было даже правило, чтобы не задеть случаем какой сервис-пак, в стандартные енумы добавлять значения, начиная с 32 позиции. Так что используйте value2symbol() как Сергей сказал.

[Murlin]

Цитата:

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

Кажется в Колумбусе было даже правило, чтобы не задеть случаем какой сервис-пак, в стандартные енумы добавлять значения, начиная с 32 позиции. Так что используйте value2symbol() как Сергей сказал.

Не надо про коламбус... У меня больная тема. Теперь из за этого правила надо переписывать неизвестно сколько кода... Наверное при внесении сервис-паков было бы легче просто сравнивать enumы, переназначая значения там где необходимо.

[gl00mie]

енумы иногда хранятся в табличных полях, так что с очередным SP пришлось бы данные перебивать, а это не так тривиально, как заменить вызов одного метода на другой.

[belugin]

Цитата:

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

Наверное при внесении сервис-паков было бы легче просто сравнивать enumы, переназначая значения там где необходимо.

И писать апгрейд скрипты

[Murlin]

Цитата:

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

И писать апгрейд скрипты

А какой смысл, все равно надо будет при занесении сравнивать те классы даже системные которые в принципе никакой модификации не подвергались при обычном ходе вещей.. Лучше уж и правда апгрейд скрипты написать... Или заносить новые энамы сравнением и назначением нового номера... Я чета не знаю где в системы бы вместо енама использовалось число.

[Murlin]

Цитата:

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

енумы иногда хранятся в табличных полях, так что с очередным SP пришлось бы данные перебивать, а это не так тривиально, как заменить вызов одного метода на другой.

По всей системе? а факт того что в SP не будет использоваться этот же метод есть? Зачем это нужно? Усложнить жизнь человеку который будет вносить новые SP???
SP - или энам занести переназначив значение, или не переназначать но каждый раз учитывать те изменения которые внесены в классы или функции там во многих местах... а вдруг забудет занесет случайно... опять выискивать ошибку исправлять и тп.
Новый enum новое значение. Как то так... Его все равно не было.

[Murlin]

Цитата:

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

И писать апгрейд скрипты

Хотя нет знаю relation на таблице...

[S.Kuskov]

Хорошая у вас подпись. Верная

[Murlin]

Цитата:

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

Хорошая у вас подпись. Верная

Наверное. Но вопрос открыт или кто то что то делает неправильно, или это баг требующий правки по всей системе. Просто поиском по AOT я нашел штук 10-20 вызовов этого метода. Все остальное про апгрейд скрипты несуществующих записей я не понял.

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

[gl00mie]

Цитата:

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

Лучше уж и правда апгрейд скрипты написать...

Так ведь их мало написать (и по возможности обеспечить идемпотентность, что в данном случае непросто) - их ещё надо выполнить, а это гарантированный простой рабочей системы, если у вас база не игрушечная; не везде лишние простои приветствуются.

Цитата:

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

Я чета не знаю где в системы бы вместо енама использовалось число.

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

[Murlin]

Цитата:

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

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

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

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

[Murlin]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

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

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

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

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

[S.Kuskov]

Цитата:

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

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

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

Цитата:

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

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

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

[Murlin]

Цитата:

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

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


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

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