Стандарт разработки VirtualTableCallWithoutParameters

1. Oleg_nsk 279 11.06.24 08:42 Сейчас в теме
При проверке кода с использование BSL сервера фиксируется наличие ошибки разработки Обращение к виртуальной таблице без параметров

Пример запроса где такая ошибка детектируется:
"ВЫБРАТЬ
|	МойРегистр.Измерение КАК Измерение
|ИЗ
|	РегистрСведений.МойРегистр.СрезПоследних КАК МойРегистр
|ГДЕ
|	МойРегистр.Ресурс = &Ресурс";


Следует ли в таком случае игнорировать ошибку или существует какой-то стандартный способ ее избежать?

Живой пример: назначение водителя на транспортное средство или его снятие с транспортного средства, а также написание функции, которая по входящему параметру Водитель ищет транспортное средство на котором он в данный момент числится.
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
2. nomad_irk 76 11.06.24 08:45 Сейчас в теме
(1)Ошибка потому, что запрос должен быть таким:
ВЫБРАТЬ
    МойРегистр.Измерение КАК Измерение
ИЗ
    РегистрСведений.МойРегистр.СрезПоследних(, Ресурс = &Ресурс)
3. Oleg_nsk 279 11.06.24 09:16 Сейчас в теме
(2)
ВЫБРАТЬ
МойРегистр.Измерение КАК Измерение
ИЗ
РегистрСведений.МойРегистр.СрезПоследних(, Ресурс = &Ресурс)


В случае если водителя сняли с транспортного средства, то запрос вернет последнее транспортное средство на котором был водитель, а должен вернуть пустую таблицу, поэтому срез по ресурсу недопустим
4. nomad_irk 76 11.06.24 09:20 Сейчас в теме
(3)значит, не используйте СрезПоследних, либо игнорируйте ошибку
5. Oleg_nsk 279 11.06.24 09:35 Сейчас в теме
(4) Посмотрел типовую бухгалтерию. Там полно подобного (см. вложение). Думаю мне не следует применять к своим разработкам стандарты более высокие, нежели используют разработчики типовых конфигураций.
Прикрепленные файлы:
6. laperuz 46 11.06.24 11:05 Сейчас в теме
(5)А потом на инфостарте появляются статьи "Как я ускорил ERP/БП/ЗУП в 100500 раз" :)
7. starik-2005 3060 11.06.24 11:19 Сейчас в теме
(6)
Как я ускорил
Срез последних без даты работает быстрее, чем с датой, т.к. выдает самые последние последние.
С другой стороны, не так часто нужно самое последнее последнее...
12. odinsmot 13.06.24 09:41 Сейчас в теме
(3)
если водителя сняли с транспортного средства, то запрос вернет последнее транспортное средство на котором был водитель, а должен вернуть пустую таблицу

В справочнике транспортных средств добавить элемент с наименованием "Снят с транспортного средства".
8. Sashares 35 11.06.24 11:26 Сейчас в теме
(1)Если это запрос в документе, то отбор по дате нужен на дату документа.
9. booksfill 11.06.24 12:23 Сейчас в теме
(1) Это зависит от того, что вы хотите получить, в своем стремлении сделать пример попонятней вы создали непонятную абстракцию.

Если вам надо получить срез последних по всем значениям измерений, то это не ошибка, "смело" (см. замечание ниже) используйте
// BSLLS:VirtualTableCallWithoutParameters-off
// BSLLS:VirtualTableCallWithoutParameters-on

Иначе следует использовать отбор по измерениям, типа
РегистрСведений.МойРегистр.СрезПоследних(, Измерение1= &Водитель).

В принципе, если нет уверенности в том, что вам не насоздовали данных будущим периодом, например, диспетчер может привязать машины водителям аж на месяц вперед, то период следует указывать всегда:
РегистрСведений.МойРегистр.СрезПоследних(&ТекущаяДата, Измерение1= &Водитель).
10. Oleg_nsk 279 13.06.24 07:45 Сейчас в теме
(9)
(1) В принципе, если нет уверенности в том, что вам не насоздовали данных будущим периодом, например, диспетчер может привязать машины водителям аж на месяц вперед, то период следует указывать всегда

Вот тут вы наверное, правы. Несмотря на то, что бизнес процесс (пока) не подразумевает ввода записей будущим периодом, мы всегда можем использовать текущую дату в качестве параметра, чтобы исключить такую ситуацию в дальнейшем, если заказчик захочет когда-то изменить логику. Таким образом ввод ограничения на параметр мог бы помочь исключить эту ошибку. Однако, тут есть еще одно обстоятельство. Для этого регистра используется опция "Разрешить итоги: срез последних". Поскольку получение актуального транспортного средства для водителя - это очень частая функция, которая будет использоваться повсеместно (например, для изменения ТС при изменении водителя на форме документа), то мы встаем перед выбором:
1) Добавить параметр текущая дата и избавится VirtualTableCallWithoutParameters, однако, несколько замедлить работу системы
2) Игнорировать VirtualTableCallWithoutParameters, но зато быстро получать нужные данные из регистра.
13. Sashares 35 13.06.24 11:14 Сейчас в теме
(10) Да нет никакого вопроса.
О каком замедлении работы системы идет речь?
Вы пробовали делать замер выполнения запроса с датой и без даты?
Неужели разница выполнения в десятках секунд измеряется?
Или все же разница в миллисекундах?
14. Oleg_nsk 279 13.06.24 13:16 Сейчас в теме
(13)

(10)
О каком замедлении работы системы идет речь?

А какое замедление можно считать допустимым? С таким подходом вообще оптимизация не нужна.
У меня нет вопроса как сделать чтобы работало.
Но есть вопрос как сделать так, чтобы были соблюдены стандарты разработки и при этом не пострадала производительность.
16. Sashares 35 13.06.24 15:34 Сейчас в теме
(14)
А какое замедление можно считать допустимым?

Которое не создает проблем при работе пользователя.

Если при открытии формы подбора запрос выполняется 10мс или 20мс, пользователь этого не заметит.
Если же при открытии формы запрос выполняется несколько секунд (или десятков секунд) - это уже заметно и создает проблемы.

У меня нет вопроса как сделать чтобы работало.


Речь о том как надо делать правильно.
Открыл пользователь документ прошлого месяца, или ввел документ будущей датой - по любой причине - в подборе будет не верная информация.

В чем проблема сделать сразу так, чтобы работало правильно всегда? Из-за какой мифической оптимизации вы готовы допускать некорректную работу системы?

Ладно, если бы речь шла об оптимизации на минуты или десятки секунд, но тут то о чем разговор?

Вы так и не привели замеры.
17. spacecraft 13.06.24 16:03 Сейчас в теме
(1) это общие рекомендации для всех виртуальных таблиц.
Это не означает сам факт ошибки. Это рекомендация проверить, что правильно используете.
Если по условию не требуется отбор, то и устанавливать параметры не обязательно.
Просто по статистике довольно частая ошибка указывать отбор не параметрами, а в секции ГДЕ (при равном получении результата).
11. booksfill 13.06.24 09:35 Сейчас в теме
(10) Именно так.

Как вариант, создать настройку программы "РазрешеноВедениеТСБудущимПериодом" и получать период в
методе:

Функция ПериодТС()
   результат = Неопределено;

   Если УтилитыСерверПрив.ПолучитьнастройкуПрограммы("РазрешеноВедениеТСБудущимПериодом" Тогда
      результат = ТекущаяДатаСеанса();
   КонецЕсли;

  Возврат результат;  
КонецФункции
Показать


Можно поместить метод в ОМ с повторным использованием возвращаемых значений, чтобы еще быстрей.

Вообще-же, это тот случай, когда решение лучше принимать на уровне бизнес-правил, если есть документ, которым разрешено проведение будущим периодом, то самое правильное отключить использование итогов для такого РС. И т.д. и т.п. случаев много, но все они больше про архитектурное решение.
15. Oleg_nsk 279 13.06.24 13:29 Сейчас в теме
(11) С архитектурой мы определились. В этой ветке я хотел собрать мнение коллег каким образом лучше получать значение измерения для ресурса. Как я понял все реализовали бы по разному и единого стандарта для этого нет.
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот