Все мы знаем, что обращение через точку эту моветон, лишняя нагрузка итд, что все нужные данные надо доставать запросом либо, например, БСПшным ОбщегоНазначение.ЗначениеРеквизитаОбъекта(). А нахрена тогда вообще точка и в каких случаях ей пользоваться? Если конфа точно не будет под нагрузкой? Если лень писать запрос?
И самое главное, почему 1С не поменяет механизм работы точки?

>Если конфа точно не будет под нагрузкой? Если лень писать запрос?
Наверное, примерно так.

>И самое главное, почему 1С не поменяет механизм работы точки?
А есть идеи на что его менять? (кроме как сделать как в тонком клиенте - т.е. просто выкинуть)

Твои предложения?

(0) Выборка данных запросом через прокладку очень быстро становится медленнее, если нужно значительное количество данных объекта. При чтении через точку при первом обращении объект читается, а затем он некоторое время кеширован, и последующие обращения через точку быстрее любых прокладок.

(1) (2) Ну очевидно, что чаще нужно меньше половины реквизитов, а еще чаще 1-2. Поэтому через точку делать запрос на 1 указанный реквизит. Если нужно много реквизитов, то пишешь запрос.

Во-первых, это красиво...

Интересно как работает точка в других ЯП с MVC моделью.

(4) И что что чаще? Вот как будет "всегда" - так можно и от точки отказываться.

(5) Во-вторых, это повышает скорость разработки и снижает затраты на сопровождение кода.

А те, кому нужна скорость любой ценой - пусть идут в Ассемблер и машинные коды.

(0) Ошибка проектирования. Не заложили достаточно гибкости. Если хотя бы ТЧ и ЧЗ всякие не тянулись бы безусловно, уже было бы терпимо.

>почему 1С не поменяет механизм работы точки?

Поздно уже. Груз легаси кода неподъёмен.

(6) В других давно пришли к парадигме CQRS.

(9) "ЧЗ" --> "ХЗ"

(0) "все нужные данные надо доставать запросом" - О ужас! В запросе тоже можно через точку доставать.

На самом деле разработчики платформы достаточно ленивы
запросто можно было это представлять синтаксическим сахаром вызова запроса

(9) 1С очень легко отбрасывает легаси-код. Вспомните как сильно отличаются редакции типовых конфигураций. Один переход на УФ чего стоит

(5) Запрос или ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Номенклатура, "Наименование") - красивее, чем Номенклатура.Наименование ???
(8) Аналогично и про скорость разработки.

(12) Если получать реквизиты "поштучно" - это во многих случаях будет ещё хуже, чем получать объект целиком (накладные расходы на исполнение запроса съедят кучу времени).

(14) Нет

(4) >> Если нужно много реквизитов, то пишешь запрос.
Как раз, если нужен одиночный объект почти полностью, то запрос писать не надо. Через точку самое то: накладные расходы на запрос будут сравнимы с чтением объекта в кэш.

(17) Если нет ТЧ.

Тоже не понимаю, почему 1С не поменяет алгоритм работы точки. Вернее, вижу только одну причину - низкий приоритет этой задачи.

Я точку иногда использую для упрощения кода, когда уверен что узким местом это не станет никогда и на увеличение общей средней нагрузки это тоже не повлияет. Т.е. не в цикле, на нетяжелых объектах и в нечасто запускаемых штуках. Оно как-то и нечасто приходится выбирать через точку или нет. Потому что обычно данные уже каким-то образом пакетно достаешь. А так, чтобы вот единичное обращение нужно было и приходилось решать через точку или нет - очень редко такое.

Первое правило оптимизации - не оптимизируй

"Все мы знаем, что обращение через точку эту моветон" - я бы не был столь безапелляционным. К реквизитам представления объекта - можно обращаться.Не моветон? К реквизитам объекта, ранее уже прочитанного в кэш - не моветон? И куда деть обратную совместимость, которую хочешь не хочешь, а тащить приходится. Вырастили хвост собаке -теперь уже не отрубишь.  А насчет запросов ради получения значений... запросы в цикле - тоже моветон :)

Само по себе "через точку" допустимо и иногда оправдано. Недопустимы только особо рукожопые варианты. Например, когда в цикле перебираются много документов с кучей реквизитов и толстыми ТЧ, и при этом разработчик херачит данные через точку. У получения данных "через точку" есть один существенный плюс - уменьшается объём кода и повышается его читабельность

(0) > И самое главное, почему 1С не поменяет механизм работы точки?

потому что всякие нубы не обладают пониманием того что точка это мета-конструкция которая позволяет писать коротко.

вОбъект2 = вОбъект1.Реквизит;
где:
.Реквизит - это инкапсуляция либо внутреннего запроса, либо получения данных из кеша значений.
внутренниый запрос обрабатывается уже скомпилированным кодом, которы быстрее кода на языке 1С.

+(24) тем самым мы имеем:
1. скорость работы
2. укороченную запись.
эти 2 вещи - бесценны для разработки.

(24) Да пусть "внутренний запрос" хоть четырежды скомпилирован. Если при этом тянется целиком объект - это нифига не очевидно и ни разу не оптимально в куче случаев. Причина у такой реализации была только одна - это было проще реализовать.

Хмм... имхо, есть ещё одна причина, когда считаю возможным отступление от канона и обращением к реквизитам "через точку": в угоду внесения минимально допустимых изменений в типовую версию.

Если бы не точка - 1с8 не взлетела бы, когда толпы семерошников пришли в нее.

Речь не про "точку", а про то как она реализована.

Точка — это символ ООП.

(26) Предлагаешь не кешировать объект, а каждый раз в базу лазять?
Что тянут всё сразу - да, как-то не очень, хз и тч можно бы и не брать...

(30) В smalltalk, как образце ООП, точек практически нет

(31) Конечно. Сейчас так и делают, только через БСП. Точку и предполагается при единичных обращениях использовать. Если хочешь закэшировать объект в "старом стиле" - это очень легко делается явно. И при этом все наглядно и понятно.

(32) smalltalk сыроват ещё

(34) Сыровата 8ка. А смалталк - давно уже отработан...

(26) > Да пусть "внутренний запрос" хоть четырежды скомпилирован.

ну дык это разрабу решать, каким образом оформлять алгоритм. есть  2 пути: запрос и через точку, разраб сам и выбирает.

не скрою, тоже думал об этом, что иногда получаем избыточный набор реквизитов объекта. И как бы я программировал "экономичные выборки". Типа:
вОбъект2 = вОбъект1.Реквизит("Код,наименование,промокод");

и мы влипаем в след. колизию: для "усеченного" объекта пришлось бы хранить в памяти словари усечения, т.е набор обрабатываемых реквизитов, тогда как для "неусеченного" объекта можно тупо использовать сингелтонные словари из метаданных. Это увеличит расход памяти на внутренний объект переменной, а их зачастую десятки тысяч.
Тут разрабам нужно выбирать тщательно.

я говорил о разных разрабах, о тех кто пилит код самой платформы и о тех, кто скрриптует на 1С.

(35) Smalltalk уже давно на свалке истории

(36) Чтобы средний разраб "хорошо решал", ему хорошо бы иметь максимально предсказуемое поведение системы. Вычитывание "мегатонного" объекта при попытке получения реквизита - это нефига не предсказуемое поведение. Чем больше неочевидной магии в системе - тем хуже "решает" средний разраб.

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

(39) >> это нефига не предсказуемое поведение
Почему? Всё задокументировано. Новичок на эти грабли практически гарантировано наступает, способный хоть капельку думать осознает и запомнит.

(39) Я бы не парился насчет "среднего разраба". Как выучится, такой и продукт будет. Это не проблема фирмы 1С.

Дооооо. Конеееечно. Железный аргумент. Чтобы все было предсказуемо, нужно сначала выучить всю доку назубок. Так можно оправдать любую ересь. Главное, чтобы была задокументирована.
Только при наличии выбора любой вменяемый человек выберет из двух систем более предсказуемую. И в среднем на более предсказуемой системе будет совершаться меньше ошибок.

Для тех, кому "мало" ЗначениеРеквизитаОбъекта() есть еще:
- ЗначенияРеквизитовОбъекта()
- ЗначенияРеквизитовОбъектов()
- ЗначениеРеквизитаОбъектов()

(41) "Новичок на эти грабли практически гарантировано наступает" - т.е. ты считаешь, что это норм? Вместо того, чтобы убрать грабли?

(43) Переходи на жаваскрипт. Там документацию вообще читать не надо...

(39) > Чтобы средний разраб "хорошо решал", ему хорошо бы иметь максимально предсказуемое поведение системы.

т.е. документацию изучить.

В рекомендациях от 1С сказано что обращение через точку "позволяет создавать компактные запросы". И там не сказано что это моветон

(36) ты придумал код из БСП. Так получаеются реквизиты контрагентов, организаций для печатных форм

(39) Оба два решения не очень, поэтому 1С оставила делать выбор разработчику.
Если отдавать через точку, только нужный реквизит, то это повысит читаемость кода, но может привести к тому, что разрабы вообще не будут способны понимать, что если обрабатываешь большой или потенциально большой набор объектов, то нужные данные лучше сразу выбрать запросом. Вместо этого возможно долбежка СУБД мелкими запросами в циклах, для получения одного реквизита объекта.

(60) особенно актуально когда тип - любая ссылка. Например поле регистратор. В обычном запросе можно ограничить выборку через выразить

+(50) Ну и не так уж трудно запомнить, что при получении реквизита ссылки через точку будет получен весь объект.

(48) Речь не о запросах

(50) О да. Лучше подождать, пока разраб в своей практике не споткнется о внезапное кэширование больших объектов. Очень педагогично.
У разраба с минимальным бэкграундом в чем-то еще кроме 1С обязательно возникнет в голове вопрос - что происходит при обращении через точку. И интуитивно предполагаешь как раз точечное обращение к БД вместо ковровых бомбардировок.
(52) Это запомнить несложно. Но запомнишь ты это только после того как споткнешься или вычитаешь в доке. Будь иначе - этого бы запоминать не пришлось вовсе. И не пришлось бы пользоваться костылями из БСП.
Не вижу больше смысла спорить об очевидных вещах.

(54) Тоже не вижу смысла спорить. Я просто не понимаю, почему нельзя запомнить простое правило и делать выбор в зависимости от ситуации.

(55) Какое еще "можно", когда "нужно"? Речь о том, что можно было лучше. Но "стокгольмский синдром", вероятно, мешает это осознать.

(45) Что ты считаешь граблями - кэширование? Или предлагается кэшировать объект частями?
Возможность прочитать объект в кэш и тысячу раз обратиться к его реквизитам без обращения к базе - реальная возможость, а не случайный баг.

(56) Как было бы лучше?

(57) Возможное улучшение действительно может заключаться в разрешении частичного кэширования. И возможности указать (как в БСП), какие реквизиты потребуются в дальнейшем.

Но это сильно усложнит реализацию, особенно в части инвалидации кэша. Не факт, что оно того стоит.

(58) Можно было просто использовать Smalltalk, там нет точек при обращении к методам объектов. Тупо через пробел

(43) А теперь сравни количество 1Сников и количество остальных программистов для бизнес-приложений ;)

(45) Т.е. ты предлагаешь не читать объект? Тогда как будет обеспечиваться синхронность данных, полученных в разные моменты времени? Блокировкой с уровнем изоляции REPEATABLE READ? Вы реально считаете, что это ускорит работу нагруженной системы?

без точек:

context->push_back(make_shared<LocalVariableObject>(p->Name,p->Type,locVarVolume));

(59) Думаю, оно того НЕ стоит
(60) Речь же не про синтаксис, а про поведение платформы при обращении через точку(или даже через Объект["ИмяРеквизита"]) Я не вижу альтернативного и при этом лучшего в 100% случаев поведения чем есть сейчас.

(63) Я был бы не против

    Структура = Объект["ИмяРеквизита1,ИмяРеквизита2,ИмяРеквизита3"]

(63) Можно было бы аккуратнее считывать тяжёлые реквизиты (строки неограниченной длины, ХранилищеЗначения) и табличные части. В остальном работает быстро.

Как это теперь нельзя использовать точку? Я что-то пропустил?

(66) >> Все мы знаем, что обращение через точку эту моветон
пишет нам сегодня зарегенный бот

PS: читать или нет ТЧ объекта при обращении "через точку" - это не вопрос. Как и предложение читать ТЧ позже при реальном обращении к ТЧ. Это не тема для обсуждения если вспомнить про многопользовательский режим работы и получение непротиворечивых данных. Если читать - то читать всё и сразу.

(68) Можно просто накладывать блокировку...

(0) Как раз ОбщегоНазначение.ЗначениеРеквизитаОбъекта(Ссылка, "Рекв") - это костыльный костыль. Никакой читабельности.

Все это ерунда
Надо встроенные в язык запросы и функциональные типы

(68) >Если читать - то читать всё и сразу.

А чего не всю базу сразу? "Непротиворечивость" нужно рассматривать в контексте.

Вообще было бы логично для чтения всего объекта из базы использовать отдельный явный вызов, а через точку читать только конкретный реквизит, если мы весь объект не читали.
Что-то вроде
КонтрагентПрочитанный = КонтрагентСсылка.ПрочититьИзБазы();

З.Ы.: ну или ПрочититьИзБазыИменемНуралиева();

(73)
>> через точку читать только конкретный реквизит
тогда станет (очень распространенными) граблями:
Рекв1 = Объект.Рекв1;
Рекв2 = Объект.Рекв2;//повторный запрос к базе

>> использовать отдельный явный вызов
Их и сейчас есть: от ПолучитьОбъект() до Запрос("Выбрать * Из ... где ссылка = &ссылка")

Вопрос: зачем и чем это лучше текущей картины?
ИМХО здесь главный критерий логичности - соответствие документации, ну и вообще такое поведение (чтение целиком и кэширование) не выглядит абсолютным костылём.

(74) Перевернем ситуацию.
Предположим, что "главный критерий логичности" соблюден. И в документации написано, что по "точке" выполняется неявное обращение к БД за этим конкретным реквизитом.
Все этим легко и прозрачно пользуются. Когда нужно пачку реквизитов получать - юзают запрос или явное ПолучитьОбъект().
И тут кто-то предлагает "а давайте по первому обращению через точку неявно вытягивать весь объект?". Как далеко его бы тут послали? Я думаю - очень далеко.

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

ну сам код можно перед компиляцией препроцессировать неким оптимизатором. для одноточечной оптимизации - в принципе все не так уж и сложно (строится на кэш-структуре):
- отловить точки относительно объектов;
- собрать для таких объектов словари ("словари усечения" у trdm);
- для каждого из построенных соответствий объект-словарь препроцессировать код: перед первым использованием - присвоить по имени объекта структуру, в которую запросом (добавленным в тот же код или типа бсп-шного) - вытянуть только то, что упомянуто в словаре.
trdm что-то типа этого имел ввиду?..
ЗЫ: ну, или заморочившись правилами оптимизации и обратимостью - сам код в конфигураторе оптимизировать - отменить, не замахиваясь на требования доработки платформы...

>>Все этим легко и прозрачно пользуются. Когда нужно пачку реквизитов получать - юзают запрос или явное ПолучитьОбъект().
Так же будет масса "специалистов" пишущих простыни "Рекв1 = Объект.Рекв1;...Рекв100500 = Объект.Рекв100500;" и удивляющихся что 1С тормозит.

Если бы мы говорили про систему написанную с нуля, тогда бы согласился: от неявного чтения через объектную модель можно вообще отказаться.

(76) >> лучше уж повторный запрос
Не лучше. Если мы говорим про средний объект(без сотен реквизитов и огромных ТЧ), то пара-тройка запросов будет не оптимальней чтения объекта целиком.

(69) Угу, и получить тормоза на ожидании блокировки... типа, хочешь изменить объект... но низззя! потому что его кто-то прочитал, например, для отчета. И так пока или сборщик мусора не уничтожит все ссылки на этот объект, или программист явно не разблокирует объект.

(72) Непротиворечивость для объекта нужна гораздо чаще, чем для базы.

(73) Т.е. ты хочешь получить кучу трудноуловимых глюков, которые не сможешь продемонстрировать исполнителю? Глюки будут возникать, когда объект будет меняться другим пользователем пока ты его читаешь.

(0) потому что это удобно. При обращении через точку - в кэш вычитывается весь объект. Последующие обращения через точку к этому же объекту вызывают обращения к памяти, а не к БД.

(81): чот вас колбасит. субъективное "удобство" аргументируете совершенно не относящимся к удобству способу ресурсозатратной реализации метода... єто нихера не удобно - это вынуждено.

(0) как то давно была большая дискуссия на эту тему на парнерском форуме, и завел ее, Тормозит, если я не ошибаюсь
в общем 1сники были не убедительны в дискуссии, как я помню
киньте сюда ту ссылку, кто найдет

(81) а если объект в базе поменялся, как кэш актуализируется при "повторном" обращении через точку?

По сути, чтение объекта целиком в кэш вместо реквизита, к которому обращаемся через точку - это вариант "упреждающего чтения (read ahead)" в райд-контроллерах. В подавляющем большинстве контроллеров есть возможность как включить эту возможность, так и отключить. А ещё, во многих реализациях есть "адаптивное упреждающее чтение", которое при чтении нескольких блоков подряд производит чтение еще нескольких после них. Что-то подобное можно было реализовать и в 1с. Обратились скажем к трем реквизитам объекта без промежуточных обращений к другим объектам  - в четвертый раз читаем весь объект в кэш.

(84): а никак. кстати, в семерке - точно так же. ожидать иного, кстати - глупо.

(85): ... или где-то вести статистику - и кэшировать те реквизиты, которые чаще всего юзаются...

Если читать только один реквизит то может получится что читаешь контрагента, потом читаешь договор и между двумя чтениями кто то влезет и изменит объект. и получится что договор не соответствует контрагенту. А если читаем сразу весь объект такого никогда не случится. Объектный подход. Ты либо читаешь весь объект, либо ничего. У регистров сведений, например, нет объектов и обращение через точку не приводит к считыванию большого объема данных.

(85) >> Обратились скажем к трем реквизитам объекта без промежуточных обращений к другим объектам  - в четвертый раз читаем весь объект в кэш.

В итоге четыре раза сходил в базу, а объект больше не понадобился. Бред же. Никакой логики.
Сейчас программист сам может решать когда и что читать и как это оптимизировать, а не рассчитывать на оптимизатор, который может не угадать.

(84) " Однако чтобы считывание происходило не при каждом обращении – данные объектов кэшируются системой. Если обращаться через ссылки к свойствам одного и того же объекта базы данных, то считывание данных будет происходить только при первом обращении, а так же после того как система выгрузит этот объект из кэша. Данные объекта удерживаются в кэше около 20 минут, но после интервала в 20 секунд при очередном обращении будет выполняться проверка того, что объект в базе данных не менялся, и, при необходимости, выполняется обновление данных в кэше. Если объект записывается в данной сессии, то он сразу обновляется в кэше. Также имеются ограничения на количество объектов хранимых в кэше. Следует заметить, что в рамках транзакции система использует отдельный кэш, поэтому обращение к данным объекта через ссылки в транзакциях гарантированно выдает актуальные данные. "
https://its.1c.ru/db/metod8dev#content:2700:hdoc

(89) Вообще да. Если что-то объемное и критичное к времени выполнения - обычно это делается одним запросом, и в выборке уже готовые данные, обращаться через точку просто нет необходимости. А там, где время не критично - можно и через точку, зачем код усложнять?

во-во.. и в тексте запроса еще отменить..пусть всё лепят ручками, через соединения.

(92): а вот хренасдва. по "ЗЫ" в (77) на коленке слепил скрипт для нотепад++ - работает, "одноточечная" оптимизация-откат кода.

(8) >> А те, кому нужна скорость любой ценой - пусть идут в Ассемблер и машинные коды.
Не прокатит. Я уже пробовал. Как только начинаешь делать что-то сверхсерьёзное, так сразу закапываешься и славливаешь тормоза на всём. Не реально на ассемблере писать учётные системы.

(82) ну вообще-то в это реализация классического Model-View-Controller в 1с.
Используется повсеместно.
И только грамотным 1сникам это кажется непонятным расколбасом.

А я всегда через точку обращаюсь, что бы было видно от кого эта переменная. Знаю, что это плохо и вредно, но так удобнее)))))

А ещё локальные переменные объявляю вначале процедуры через Перем и вношу описание, для чего и от чего они. Тоже ересь полная, но так удобнее и красивее. Зато минимизируются "зависшие" переменные

(89) Опционально должно быть. Директива #КэшированиеОбъекта Адаптивное|Отключено|Полное в коде. А по умолчанию - отключено.

Думаю, в принципе это ООП-стиль - сразу получать весь объект. В этих ихних ООП не делают отдельных объектов для получения 1-2-3 полей основного объекта. Сразу тащится весь объект и уже из него получаются нужные поля

ИНН = Контрагент.getИНН();
КПП = Контрагент.getКПП();
Адрес = Контрагент.getАдрес();

а сколько там полей внутри объекта Контрагент и сколько из них понадобится уже никого не парит

(99)  И какой в этом смысл? Вообще не пойму, чем вам помешало кэширование объекта в переменную?

(98) Давно ли ты заглядывал в "эти ихние ООПы"? Просветись про CQRS.

(100) Подскажешь какой-нибудь фреймворк на java / c# использующий подход CQRS?
Судя по поверхностному гуглению CQRS - примерно с таким же успехом можно говорить, например, - "всё прогрессивное человечество давно перешло на функциональный стиль" - не споря даже с самим высказыванием, при чём здесь вообще тема ветки?

имхо, есть проблема не написания кода через точку, а есть проблема дефицита грамотных архитекторов, которые следят за количеством и размером ТЧ и бьют по рукам за использование в документе реквизитов с типом ХЗ

(0)Вот это темка :)

Т.е. мы получаем в процедуру переменную "Источник" типа СсылкаНекийДокумент. И теперь "Ичтоник.Номер" нельзя писать? А как тогда надо?

(101) Причем тут фреймворк? Это архитектура конкретного приложения.

(101) Google("asp.net cqrs") и т.п.

(0) Ну например обращаться к свойствам и методам объектов, не относящимся к объектам БД

Давно уже было подмечено (одним английским писателем), что есть тупоконечники, есть остроконечники, и есть ещё странные люди, которые яйца тупо жрут.

(104) Просто после слов типа "ошибка проектирования" и "в других давно пришли к парадигме CQRS" ожидается указание на том в чём именно ошибка и кто эти самые "другие".
Про фреймворки - есть, например, идея ORM - для него есть куча примеров реализацией (самая известная, наверное, Hibernate).
(105) По Google("asp.net cqrs") находится что-то про микросервисы.
И собственно о делении "запросов" и "транзакций". Это я и при первом поиске нашёл и ещё раз задам вопрос - при чём здесь тема ветки?

Ответы только убеждают в том что это обычный вброс форумного "эксперта".

(103) "получаем переменную "Источник" И теперь "Ичтоник.Номер" нельзя писать?"

Нельзя. Получишь ошибку ))))

Я ранее высказал мысль "Если читать - то читать всё и сразу", с которой не все согласились. Якобы допустимо "дочитать" позднее необходимые данные объекта... Вот вам пример из типовых. Я его озаглавлю фразой "А сегодня в завтрашний день, не все могут смотреть. Вернее смотреть могут не только лишь все, не каждый может это делать." :)

При обмене данными, в современных конфигурациях, сначала получается количество объектов к выгрузке (точка "А") функцией ПланыОбмена.ВыбратьИзменения(), которая присваивает номер сообщения обмена всем прочитанным записям регистрации изменений. А через пару десяток строк алгоритма происходит формирование самого сообщения обмена (точка "Б") с помощью функции ПланыОбмена.ЗаписатьИзменения(), которая читает все зарегистрированные изменения для узла обмена...

Вы можете спросить "Ну и где здесь криминал?"

Предположим, что между двумя этими чтениями, между точками "А" и "Б" алгоритма будет изменён какой-либо объект - что произойдёт далее, в будущем? Сразу предупрежу: изменение объекта будет включено в формируемое сообщение обмена и отправлено в узел...

Казалось бы никакой тут проблемы из-за чтения с последующим "дочитыванием" тут нет. Или есть?

[Sorry за холивар, пятница же]

(110) Принцип должен быть "если что-то читать, то читать согласованно". А вот что читать — те реквизиты, от которых зависит логика транзакции. Если для транзакции нужен только реквизит Статус, то все остальное можно не читать. И оно даже может измениться от момента чтения до момента записи.

Другое дело, что в 1С такое невозможно из-за пессимистической блокировки. Пессимистическая блокировка дает более сильные гарантии. Мы можем спокойно "дочитать" позже, например, ТЧ. И быть уверенными, что если кто-то успел изменить ТЧ, то пессимистическая блокировка это не пропустит.

В случае с обменом проблемы нет по другой причине. В данном случае логика транзакции зависит от того, был ли изменен объект с момента последнего обмена. Он мог быть изменен 100 раз, и если он изменится 101-й раз в интервале от А до Б, это ничего не меняет в логике.

Проблема естьи ч ней сталкивался несколько раз с тех пор как стали применять такой алгоритм в типовых.
- Видишь суслика?
- Нет.
- Вот и я не вижу. А он есть.

imho проблема не в скорости как таковой - проблема в том, что скорость "с точкой" более непредсказуема, чем запросом. в том смысле. что если два схожих запроса "при прочих равных" (но даже на разных данных) отработают за приблизительно одинаковое время, то два использования "точки" могут сильно удивить...

Кстати, проводил недавно исследования (в SQL-профайлере), и выяснил, что:

1. Чтение ссылки не вызывает обращения к базе. То-есть если есть Док типа "ДокументСсылка", то
А = Док.Ссылка.Ссылка.Ссылка.Ссылка;
не вызовет обращения к базе данных

2. Чтение реквизитов через ЗаполнитьЗначенияСвойств вызывает чтение, как через точку.
То-есть, если есть Док типа "ДокументСсылка", то

Реквизиты = Новый Структура("Номер, Дата, Организация");
ЗаполнитьЗначенияСвойств(Реквизиты, Док);

вызовет чтение всех табличных частей документа

(113) Об этом и речь. Текущая реализация - это классический WTF. И занесение ее в документацию этого никак не отменяет.
(114) Богатое исследование. И какое объяснение дают "исследователи" по первому пункту? 1С кеширует все ссылки в базе и строит граф зависимостей? :)

(114) А! Или ты просто про то, что 1С разруливает тавтологии? Ну, это скучно. Так только новички на первых порах писать могут.

(114) Запросом надо читать

(114) а как тебе такое:
выполнение Строка(Ссылка) не читает весь объект

Такое ощущение, что некоторые забыли основы языка :) Например, как формируется представление ссылки. Раньше это было "внутри" платформы, а сейчас "вынесено наружу" - ОбработкаПолученияПолейПредставления() и ОбработкаПолученияПредставления()...
Короче, (114) - чтение объекта вызывает обращение к реквизиту "Организация".

откуда такие ощущения?

(120) От фразы "Чтение ссылки не вызывает обращения к базе" :)

у меня сделан 3-й вариант обращения через точку - вызов модуля повторного использования.

Например,

_ПовтИсп.ЗначРекв(СтрМатериал.ЕдиницаИзмеренияМатериала,"ЕдиницаПоКлассификатору",Неопределено)