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

[Murlin]

Цитата:

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

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

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

[belugin]

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

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

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

[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 применительно к определенной логике - нет? Если нет - то и апгрейд скриптов не нужно. А если есть - то как быть?

[raz]

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

[belugin]

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

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

[Murlin]

Цитата:

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

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

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

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

[belugin]

Цитата:

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

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

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

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

[Murlin]

Цитата:

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

Это конечно да, но такое я бы назвал хардкодом.

Да майкрософту тоже надо от кода отказаца типа вот этого
while select inventTrans
where inventTrans.TransType > a && inventTrans.TransType < b

либо отказаться от использования метода index2Symbol

[db]

Цитата:

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

Да майкрософту тоже надо от кода отказаца типа вот этого
while select inventTrans
where inventTrans.TransType > a && inventTrans.TransType < b

либо отказаться от использования метода index2Symbol

да что вы так упелись то
вызов index2Symbol с значением (не индексом) енума в качестве параметра это не осмысленное желание/правило мс, а обычный баг сделанный обычным разработчиком. От того что он работал в это время в мс ничего не меняется - это просто баг (проявляется он только не всегда). Таких кривых вызовов по всему приложению dax2009 ru8 с sl2 слоем около десятка - поправить 10 минут и зарегистрировать для очистки совести в мс. зачем всё усложнять?

[Murlin]

Цитата:

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

да что вы так упелись то
вызов index2Symbol с значением (не индексом) енума в качестве параметра это не осмысленное желание/правило мс, а обычный баг сделанный обычным разработчиком. От того что он работал в это время в мс ничего не меняется - это просто баг (проявляется он только не всегда). Таких кривых вызовов по всему приложению dax2009 ru8 с sl2 слоем около десятка - поправить 10 минут и зарегистрировать для очистки совести в мс. зачем всё усложнять?

Вот я про это и пишу, баг это или не баг...
Либо делаем enum с разрывом, тогда баг, либо без разрыва тогда наш баг.

[dech]

Цитата:

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

Вот я про это и пишу, баг это или не баг...
Либо делаем enum с разрывом, тогда баг, либо без разрыва тогда наш баг.

Делайте енум с разрывом и исправляйте на value2Symbol() и хватит уже морочить всем голову!

[Raven Melancholic]

Что-то чисто технический вопрос вызвал такой всплеск эмоций.
Мне кажется, что система, в которой работаешь волей или неволей задает некоторые правила, которым следует следовать (тавтология). Может быть они не всегда прямо указаны, но большинство их принимает. Учитывая, что никто не работает в одном месте "навсегда", думаю, что всяким писанным и неписанным правилам стоит следовать хотя бы для того, чтобы коллегам, пришедшим на наше место было оставлено привычное окружение.
Нумерация энумов из того же вопроса. Прямо нигде не сказано про эту нумерацию. Но косвенно, смотрим мастер создания финансовых аналитик (до DAX20012), там сразу предлагаются значения со 100. Смотрим энумы LedgerJournalACType, LedgerPostingType, LedgerJournalType и прочие - там явно на разных слоях принято использовать разные диапазоны.
В чем смысл ухода от этой практики исходя из того, что в нескольких местах неправильно применен один метод?
Murlin, конечно Ваше право применять Ваш подход, но пожалейте тех, кто придет на Ваше место, когда Вы сами решите уйти с текущей работы (Вы же не рассчитываете, что будете работать только тут и никто не придет, пока Вас не вынесут с почестями вперед ногами).
PS: кстати, при обновлении намного проще решить конфликты в коде, чем конфликты в энумах. Код классов сравнивается легко, а вот энумы полностью копируются на слой изменения и понять, что в новом нижележайшем коде другие значения не совсем очевидно.