Использование атрибута «Устаревший»
Когда вы GROUP BY в запросе, ваш набор результатов будет включать одну строку для каждого отдельного набора значений в вашем списке GROUP BY. Например, причина, по которой вы получаете две строки для записей OPEN для раздела «Техническая поддержка», заключается в том, что для TRUNC(t.create_date) есть два различных значения, в результате чего получается две группы и, следовательно, две строки в наборе результатов.
Чтобы избежать этого, прекратите группировку по TRUNC(t.create_date).
SELECT ROW_NUMBER() OVER (ORDER BY q.english_Name DESC) as id,
COUNT(t.id) AS ticket,
q.english_name queue_name,
ts.code current_status,
COUNT(t.assigned_to) AS assigned,
(COUNT(t.id)-COUNT(t.assigned_to)) AS not_assigned
-- ,trunc(t.create_date) create_Date
FROM ticket t
INNER JOIN ref_queue q
ON (q.id = t.queue_id)
INNER JOIN ref_ticket_status ts
ON(ts.id=t.current_status_id)
where t.create_date between '18-FEB-19' and '24-FEB-19'
GROUP BY q.english_name,
ts.code
-- ,trunc(t.create_date)
5 ответов
Шаг 1. Пометьте элемент или класс как [Устаревшие]
Шаг 2. Обновите все внутренние применения элемента или класса, чтобы либо использовать новый подход, который заменяет устаревший подход, либо отметить этот элемент или классифицируйте себя как [устаревший]
Шаг 3. Если вы пометили новый материал как [устаревший] на шаге 2, повторите этот шаг по мере необходимости.
Шаг 4. Удалите все устаревшие члены и классы, которые не являются ни общедоступными, ни используются устаревшими общедоступными членами или классами.
Шаг 5. Обновите документацию, чтобы дать более четкое описание подхода, рекомендованного для замены любых общедоступных устаревших членов или классов.
В конце этого у вас не будет устаревшего кода, который используется исключительно внутренним кодом. Там нет ничего, чтобы сказать, что вы должны сделать все это за один раз, хотя; на каждом этапе вы добились прогресса. Время между началом шага 1 и завершением шага 5 может составлять 5 секунд или 5 лет, в зависимости от многих факторов (большинство из них связано со сложностью).
Кстати, если кому-то будет легко игнорировать предупреждения компилятора, проблема не в [Устаревшем]. Тем не менее, одна из причин не оставлять такие вызовы в коде надолго (то есть сделать это как можно скорее до шага 2) состоит в том, чтобы убедиться, что люди не привыкнут к предупреждениям компилятора, поскольку они являются частью привычный ответ на компиляцию кода.
Это не прямой случай. Если вы удалите методы из работающего приложения и проведете рефакторинг кода, вы создадите возможность появления новых ошибок и поломки работающего приложения. Если это приложение критически важно, воздействие может быть огромным и стоить компании больших денег, подобные изменения должны быть тщательно спланированы и протестированы. В этом случае маркировка устаревших методов может стоить того, чтобы они не позволяли людям использовать их в дальнейшей разработке, что облегчает последующий рефакторинг. Однако если приложение не является критически важным или если вероятность появления ошибок невелика, то может быть лучше провести рефакторинг, если у вас есть время. В конечном итоге добавление атрибута [Obsolete] немного похоже на задачу, и его использование зависит от многих факторов.
Это зависит от обстоятельств. Да, вы МОЖЕТЕ провести рефакторинг кода. МОГУТ ВЫ?
Проблема в том, что вы МОЖЕТЕ выполнить рефакторинг ВМЕСТЕ ОДНОЙ ПРОГРАММЫ. Это намного сложнее, если API является общедоступным, и вы просто НЕ МОЖЕТЕ реорганизовать код с помощью своего API. Вот для чего создан Obsolete.
Если API является внутренним по отношению к вашему коду, то рефакторинг - это правильный выбор. Очистите код, не оставляйте беспорядка.
Но если публичный API изменяется, это следует - по возможности - делать медленно.
Остальное пока остается субъективным. Мне не нравится "устаревшее" для внутренних API.
Думаю, это субъективно. Если это внутренний и довольно быстрый процесс, я бы внес изменения.
Однако у меня также была ситуация, когда соответствующий рефакторинг занимал намного больше времени (много вызовов по всей базе кода), и в этом случае я использовал атрибут [Устарело] . В этом случае новая разработка будет использовать новые функции, и тот, у кого есть время, будет выполнять рефакторинг до тех пор, пока все вызовы не исчезнут, а это означало, что метод можно было удалить.
Я использовал его раньше как своего рода временное положение дел, когда у нас есть старый код, который нужно реорганизовать в конечном итоге , но не срочно . Чаще всего это тот случай, когда был написан какой-то новый код, который выполняет работу лучше, чем то, что было раньше, но ни у кого в команде нет времени вернуться и заменить много старого кода в данный момент. Очевидно, это подразумевает ситуацию, в которой простая замена сразу не возможна (иногда новый код делает почти все, что делал старый код, но есть небольшая часть функциональности, которая еще не реализована) .
Тогда наличие всех этих предупреждений компилятора будет постоянным напоминанием для кого-то вернуться и завершить рефакторинг, когда у него появится немного свободного времени.
Хорошо это или плохо - это довольно субъективно. Это инструмент, как и любой другой.