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

[Murlin]

Цитата:

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

Допустим мы вводим на слое usr в enum LedgerTransType со следующим по порядку значением. Наш код чего-то разносит, и в LegerTrans попадает некоторое количество записей с value 5. Если мы ставим сервис пак, в котором добавлено другое значение с тем же value, то нам надо перелопатить LedgerTrans и присвоить его полю новое значение. Елси мы этого не сделаем, то сисмеа будет интерпретировать это значение поля как значение из сервиспака, а не со слоя usr.

Зачем? Нет у вас записей в LedgerTrans с новым значением 5, вернее они есть но это старое значение 5 а не новое 5. Вам нужно сделать новое 5 числом 6.
Relation да придется исправить, но вам придется в ином случае исправлять методы Index2Symbol, и помнить про этот баг..
Я знаю что это тип int, который хранится в БД. 7 лет в аксапте достаточный срок чтобы это узнать Но само значение 5 не несет никакого абсолютно смысла, даже инициализация полей записи производиться ч/з enum, а не через его значение.

[belugin]

Цитата:

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

Зачем? Нет у вас записей в LedgerTrans с новым значением 5, вернее они есть но это старое значение 5 а не новое 5.

К сожалению, 5=5, поэтому система не может отличить старую пятерку от новой и придется писать апгрейд скрипт. Вы можете поставить простой эксперимент, для проверки этого равенства

[Murlin]

Цитата:

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

К сожалению, 5=5, поэтому система не может отличить старую пятерку от новой и придется писать апгрейд скрипт. Вы можете поставить простой эксперимент, для проверки этого равенства

По мойму мы вошли в цикл...
Это новая сущность какое значение 5 или 138 она будет иметь значения не имеет, кроме того что есть в relation.
Зачем нужны апгрейд скрипты? Что конкретно будет ими обновляться? Значения в таблице 5 на 6? Зачем? Новой сущности можно дать номер 6 и ничего не изменится, никаких скриптов запускать не надо.

[sukhanchik]

Цитата:

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

Зачем нужны апгрейд скрипты? Что конкретно будет ими обновляться? Значения в таблице 5 на 6? Зачем? Новой сущности можно дать номер 6 и ничего не изменится, никаких скриптов запускать не надо.

А исторических данных, где уже использовалось значение 5 применительно к определенной логике - нет? Если нет - то и апгрейд скриптов не нужно. А если есть - то как быть?

[Murlin]

Цитата:

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

А исторических данных, где уже использовалось значение 5 применительно к определенной логике - нет? Если нет - то и апгрейд скриптов не нужно. А если есть - то как быть?

В аксапте вроде нету предопределенных записей как в 1Ске, откудова они возьмутся

[sukhanchik]

Цитата:

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

В аксапте вроде нету предопределенных записей как в 1Ске, откудова они возьмутся

Ээээ а у Вас нет рабочей Аксапты? Вот в ней и все записи и есть предопределенные

[S.Kuskov]

Цитата:

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

А если есть - то как быть?

В этой ветке Murlin предлагает в случае конфликта своего элемента перечисления и нового системного, вместо обновления старых значений в БД, переопределить номер нового системного элемента перечисления.

Почему так делать опасно уже здесь написали, но видимо недостаточно убедительно

[sukhanchik]

Цитата:

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

В этой ветке Murlin предлагает в случае конфликта своего элемента перечисления и нового системного вместо обновления старых значений в БД, переопределить номер нового системного элемента перечисления.

Почему так делать опасно уже здесь написали, но видимо недостаточно убедительно

Ааа.... возможно я не так понял. Тогда да, апгрейд-скрипты конечно не нужны и проблемы только в коде. Хотя останется 2 проблемы:
1. Ситуация со знаками > и < (я про это писал) при сравнении значений енумов
2. Ситуация, когда вместо перечисления конкретных значений енума - указывается отрицание оставшихся значений. Ну, к примеру, можно написать:

switch (x)
{
      case 1,2,3:
..................
      default: 
}

А можно написать так:

if (x !=4)

Но это все проблемы именно анализа кода, а не данных.
Предопределенные данные могут возникать тогда, когда эти данные выпускает сам МС. Например, шаблоны отчетов для генератора финотчетности (ГФО). Тут конечно нельзя так просто отбросить именно МС-овские енумы.

Также тут надо понимать масштабы обновлений. Одно дело сервис-пак, который вообще могут не ставить, а только вытащить отдельные нужные куски.
Другое дело - апгрейд на новую версию. В новой версии - значения енумов скорее всего сохранятся. И там уже так просто не перебьешь.
И еще момент - с т.з. сравнения элементов в АОТе - удобнее, когда мало объектов, которые расположены на слое от МСа и на своем слое. В этом плане - проще не МСный код править (для исправления значения енума), а свой, чтобы не увеличивать количество объектов, расположенных на нескольких слоях.

Так что если не смотреть вперед на обновление версий - то, в общем-то вариант, когда при конфликте значений берется значение не от МС - вполне жизнеспособен.

[S.Kuskov]

Цитата:

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

2. Ситуация, когда вместо перечисления конкретных значений енума - указывается отрицание оставшихся значений.

Эмм... не понял вас. Я вижу проблему при любом использовании числового значения элемента перечисления вместо его имени.

[Murlin]

Цитата:

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

В этой ветке Murlin предлагает в случае конфликта своего элемента перечисления и нового системного, вместо обновления старых значений в БД, переопределить номер нового системного элемента перечисления.

Почему так делать опасно уже здесь написали, но видимо недостаточно убедительно

что именно опасного? т.е. действительно "опасного" а не то что вы с формы не перейдете на другую форму. relation - да
код вида
inventTrans.TransType > a и inventTrans.TransType < b
по большим сомнением... Т.к. выпуская sp с новым enumом
я думаю в нем будет исправление
inventTrans.transtype>a и inventTrans.TransType<c

[dech]

Цитата:

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

что именно опасного? т.е. действительно "опасного" а не то что вы с формы не перейдете на другую форму. relation - да
код вида
inventTrans.TransType > a и inventTrans.TransType < b
по большим сомнением... Т.к. выпуская sp с новым enumом
я думаю в нем будет исправление
inventTrans.transtype>a и inventTrans.TransType<c

Скорее всего вы не найдёте в системе таких енумов, где значение b является последним, а уж тем более, где между a и b есть разрыв. Обновление таких енумов не затрёт старые значения, а только лишь дополнит. Так что такой код ошибку не вызовет, хоть он и написан не очень корректно. Кстати, мне встречался такой код, где был добавлен новый элемент в енум, причем в коде забыли прописать подобную строку:

inventTrans.transtype>a && inventTrans.TransType<c

Приходилось самому исправлять.