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

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

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

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

[belugin]

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

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

Если начинать свои идентификаторы с, допустим, 100, то надо просто обновить приложение и всё

[raz]

ИМХО, топикастер не знает, что значения енумов в БД хранятся в виде целых чисел, и только в аксапте отображаются нужным тестом. Иначе не могу себе объяснить его упорство.

[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 и ничего не изменится, никаких скриптов запускать не надо.

[belugin]

Есть ранее введенный элемент слое USR, у которого значение 5
Есть новое значение на слое SYP у которого значение 5
Для первого элемента уже введены данные со значением 5.
Я не могу поменять для нового элемента с SYP значения с 5 на 6.

Хотя в принципе, могу это перекрыть, но
- это будет отдельное изменение, за которым надо ухаживать
- надо будет при каждом апгрейде обходить все релейшены, где эта штука упомянута по value, и прочие данные

[sukhanchik]

Цитата:

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

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

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

[Murlin]

Цитата:

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

Есть ранее введенный элемент слое USR, у которого значение 5
Есть новое значение на слое SYP у которого значение 5
Для первого элемента уже введены данные со значением 5.
Я не могу поменять для нового элемента с SYP значения с 5 на 6.

Хотя в принципе, могу это перекрыть, но
- это будет отдельное изменение, за которым надо ухаживать
- надо будет при каждом апгрейде обходить все релейшены, где эта штука упомянута по value, и прочие данные

Так и так и так вам следить или за изменениями в коде, или за relationнами.
Что проще и что удобнее поддерживать, что удобнее заметить, исправить и тп.

[Murlin]

Цитата:

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

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

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

[belugin]

Цитата:

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

Так и так и так вам следить или за изменениями в коде, или за relationнами.
Что проще и что удобнее поддерживать, что удобнее заметить, исправить и тп.

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

[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. Ситуация, когда вместо перечисления конкретных значений енума - указывается отрицание оставшихся значений.

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

[sukhanchik]

Цитата:

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

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

Не... я тут имел в виду общую проблему, которая в принципе возникает при любом добавлении нового элемента енума. Это не относится к числовому представлению.

Пример (АХ 2009):
Тип партнера договора (RContractPartnerType). Штатно этот енум имеет 2 значения: Клиент и Поставщик (будем считать, что у нас нет слоя с зарплатой, где еще добавляется сотрудник).
В коде, который относится к обработке клиентских договоров можно встретить 2 варианта:
1.

if (rcontractTable.RContractPartnerType == RContractPartnerType::Cust)

и
2.

if (rcontractTable.RContractPartnerType != RContractPartnerType::Vend)

как вариант вот так:

if (rcontractTable.RContractPartnerType == RContractPartnerType::Cust)
{
}
else
{
}

Теперь представим себе, что мы добавляем новое значение в енум RContractPartnerType.

В зависимости от предназначения этого нового элемента - вышеуказанные конструкции нам придется подправить или возможно вообще видоизменить (например, if ... else преобразовать в switch)

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

[dech]

Это конечно да, но такое я бы назвал хардкодом.
Обязательно надо использовать switch-case. А по возможности разбить на подклассы, если нам это будет удобно.

static SalesFormLetter  construct(DocumentStatus    document,
                                  boolean           getParmId = true)
{
    switch(document)
    {
        case DocumentStatus::Confirmation       :   return new SalesFormLetter_Confirm           (getParmId);
        case DocumentStatus::PickingList        :   return SalesFormLetter_PickingList::construct(getParmId);
        case DocumentStatus::PackingSlip        :   return new SalesFormLetter_PackingSlip       (getParmId);
        case DocumentStatus::ProjectPackingSlip :   return new SalesFormLetter_PackingSlipProject(getParmId);
        case DocumentStatus::Invoice            :   return new SalesFormLetter_Invoice           (getParmId);
        case DocumentStatus::ProjectInvoice     :   return new SalesFormLetter_InvoiceProject    (getParmId);

        default : throw error(strfmt("@SYS19306",funcname()));
    }

    throw error(strfmt("@SYS19306",funcname()));
}