Уточнение запросов в цикле. Отключить контроль на уровне запроса, а не цикла,
Сейчас проверка работает по принципу подсвечивания цикла, внутри которого идет запрос. Однако, слишком много ситуаций в жизни, где запрос в цикле - вполне обоснован. Чаще всего это какие-то слишком простые запросы, на уровне получения параметра из регистра, или проверок каких то. И переделывать их - просто не реально и смысла в этом нет.
Предложение - сделать возможность указать в самом запросе, что я не хочу контролировать - в цикле он делается или нет. Проблема - сейчас программист пишет код, вызывает какую-то общую функцию модуля в цикле, где есть запрос, на который он влиять не может, и ему нет смысла вообще в это вникать. Однако - он увидит в цикле ошибку, и начинает лазить и искать. Лучше было бы, если бы я, как разработчик этой функции - сказал бы, что я допускаю использовать этот запрос в цикле.
Аналогично - был код, которые брал данные по значению реквизита (допустим), теперь условия усложнились, и этот кусок переписали на запрос, и там всегда, по сути, будет возвращаться или одна строка, или ни одной, там даже ПЕРВЫЕ может стоять, в идеале. Так вот - теперь у меня по конфе вылезло 100 мест где вылезла ошибка, связанная с тем, что теперь есть запрос в цикле.
@DoublesunRUS зацени! хорошее предложение.
В общем случае не представляю как это сделать, чтобы это было полезно.
В общем случае не представляю как это сделать, чтобы это было полезно.
В процедуре где выполняется поиск вызовов запроса - просто проверить Suppression-Manager на наличие подавления, если есть - просто не включать вызов запроса в список.
com.e1c.g5.v8.dt.check.settings.ISuppressSettingsManager.isSuppressed(Object, String, String) - вот сервис для инжектинга
private Map<String, String> getMethodsWithQuery(Module module, Set<String> queryExecutionMethods,
IProgressMonitor monitor)
{
...
if ((isQueryExecution(dfa, queryExecutionMethods)) && !suppressSettingsManager.isSuppressed(dfa, CHECH_ID, BslPlugin.PLUGIN_ID))
{
...
И как мне это поможет? Он же хочет вешать метку на текст запроса. То есть перед Запрос.Текст или Запрос = Новый Запрос("Текст") Это я должен для и не так быстро работающей проверки добавить еще дополнительный поиск отключений? И ради чего? Чтобы кто-то вместо трех подавлений написал одно?
Он же хочет вешать метку на текст запроса
@DitriXNew вроде бы явно ни где не говорил что нужно именно на уровне определения текста запроса (или внутри текста запроса) управлять. Я предлагаю (пока единственно-возможный) вариант - отключать на уровне места выполнения запроса - это позволит снизить количество мест в вышестоящих процедурах с циклами. Сейчас связи текста запроса и места выполнения запроса - строго говоря, нет. Код часто написан так что текст запроса и его выполнение разнесены далеко друг от друга.
Чтобы кто-то вместо трех подавлений написал одно?
Да, чтобы вместо 100 подавленй написал одно. как написано в предложении.
Так отключение на уровне места выполнения запроса это функционал, который предоставляет сам механизм диагностирования. Зачем что-то дополнительно проверять?
Зачем что-то дополнительно проверять?
Это было бы верно, если бы ты не делал поиск по вызовам процедур - в этом случае, регистрация ошибки выполняется по месту цикла с вызовом метода - и да, там можно сейчас включать подавление, но было бы удобней для таких случаев выключать на уровне места выполнения запроса внутри метода вызываемого в цикле.
Либо тогда отключи эту функциональность поиска локальных вызовов методов с выполнением запросов. :) и не будет проблем
Может сразу проверку удалить из плагина? Тогда точно проблем не будет.