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

[Murlin]

Цитата:

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

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

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

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

[Murlin]

Цитата:

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

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

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

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

[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

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

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

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

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

[dech]

Цитата:

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

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

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

[Murlin]

Цитата:

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

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

Так не пойдет... непорядок.

[kair84]

Перечитал топик, и действительно, чуть мозг не взорвался.

index2Symbol() - если в него передавать value - баг, и однократно "просканировать" код на предмет вызова метода, не так уж и сложно

Enum с разрывом - нормальная практика,

Цитата:

inventTrans.TransType > a и inventTrans.TransType < b

в этом случае inventTransType не самый удачный пример, лучше обратить внимание на StatusIssue StatusReceipt и другие, когда элементы Enum-a действительно отражают стадии какого либо процесса, и чтобы добавлять элементы в такие Enum-ы, нужно 10 раз подумать, а если у Вас до, после, или между такими этапами добавляются свои, то лучше создать второй Enum типа StatusIssueSub, и соответственно поле для него, и предшествовать, продолжать или детализировать процесс сколько влезет

[Murlin]

Цитата:

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

Перечитал топик, и действительно, чуть мозг не взорвался.

index2Symbol() - если в него передавать value - баг, и однократно "просканировать" код на предмет вызова метода, не так уж и сложно

Enum с разрывом - нормальная практика,

в этом случае inventTransType не самый удачный пример, лучше обратить внимание на StatusIssue StatusReceipt и другие, когда элементы Enum-a действительно отражают стадии какого либо процесса, и чтобы добавлять элементы в такие Enum-ы, нужно 10 раз подумать, а если у Вас до, после, или между такими этапами добавляются свои, то лучше создать второй Enum типа StatusIssueSub, и соответственно поле для него, и предшествовать, продолжать или детализировать процесс сколько влезет

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

[kair84]

inventTransType я привел в пример, чтоб нагляднее объяснить где имеет смысл конструкция "< >" с участием ENUMов. Категорически не предлагаю, и сам, не изобретаю велосипед. На все остальные Ваши вопросы уже ответили, внятно и доходчиво, почему Вы этого не замечаете ? вот это вопрос. Если у Вас такая твердая позиция, делайте по своему, зачем Вам одобрение АХ сообщества для этого ???

А что будет если ...

[RVS]

Цитата:

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

Гипотетическая ситуация

уже сильно...

Цитата:

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

Однократно можно также изменить relation и код про который я писал.

таак...

Цитата:

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

Ничего вы не меняете абсолютно.

... фига се...

Цитата:

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

Вопрос был в том что будет если будет обновления лежащие на нижних слоях, опять ничего не меняется.

Слушайте.. изложите уже внятно.. вня-тно.. ЧТО вы хотите получить. Еще лучше - если Вы перед этим ТАК ЖЕ ВНЯТНО - изложите, "что, из того, что я вижу - мне не нравится.. (почему-то.. гы..)"

Вопросы, на которые не могут ответить взрослые - называются (и являются, кста.. ) - ДЕТСКИМИ.. было уже.. Нарайяне )

NP so far

[Raven Melancholic]

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

[Raven Melancholic]

Я переводил несколько приложений с версии на версию.
Просто по опыту понимаю, что различия в коде, в большинстве случаев, можно решить прямо в утилите сравнения. А вот разницу в релейшенах, значениях енумов в этой утилите не решить. Нужно её закрывать и вносить изменения прямо в AOT,

[RVS]

Взялось, похоже, вот отсюда "Я могу взорвать вам мозг!!!"

Я - тоже перевел.. не одно приложение.. с версии на версию. Крайний раз - работал подручным у Вашего, Алексей, знакомого.. в кондитерах который был..

Разговор, ИМХО - не о проблемы. Проблемы - нет, как таковой.

Разговор о том, что некоторые люди вместо того, чтобы почитать, как правильно репортить баги - начинают кричать а-ля "Я могу взорвать вам мозг!!!"

Что забавно, согласитесь..