Вход | Регистрация
    1  2  3   
1С:Предприятие :: 1С:Предприятие 8 общая

ОФ. Происходит ли обращение к БД при работе с реквизитами объекта?

ОФ. Происходит ли обращение к БД при работе с реквизитами объекта?
Я
   Тенепопятам
 
10.06.21 - 16:58
Вопрос следующий. В коде программы нужно периодически обращаться к реквизитам документа. Это можно делать через объект, а можно через ссылку. Правильно я понимаю, что если обращаться через ссылку, то при каждом обращении к реквизиту выполняется запрос к БД, а если через объект, то реквизиты считываются из оперативной памяти, куда они были записаны при считывании объекта? Как в этом контексте грамотнее организовать работу с объектами 1С, через ссылку или через объект?
 
 Партнерская программа EFSOL Oblako
   ДенисЧ
 
1 - 10.06.21 - 17:02
Через ОбщегоНазначения.ПолучитьРеквизитыОбъекта(), разумеется
   lodger
 
2 - 10.06.21 - 17:03
вроде ещё не пятница.
   Сурьма
 
3 - 10.06.21 - 17:04
(0) Объект у тебя откуда берётся?
   Тенепопятам
 
4 - 10.06.21 - 17:38
Не важно, откуда он берется, просто хочется понимать плюсы и минусы.
   DTX 4th
 
5 - 10.06.21 - 17:40
Ссылка - это только ссылка, объект - это документ целиком.
При обращении к реквизиту ссылки подгружается объект целиком, если он еще не был подгружен. При втором обращении к другому реквизиту запроса к БД не будет
Если нужна скорость, то (1)
   ДенисЧ
 
6 - 10.06.21 - 17:43
(5) "При втором обращении к другому реквизиту запроса к БД не будет"

Зависит от интервала обращения ))
   acht
 
7 - 10.06.21 - 17:46
(4)  1С:Предприятие 8.3. Практическое пособие разработчика, Занятие 14 (3:20) Оптимизация проведения документа «Оказание услуги», Теория: устройство кеша
   masenshi
 
8 - 10.06.21 - 18:02
(0) А можно получить значения нужных реквизитов через запрос. Вроде так быстрее всего, т.к. получаешь не все подряд а только нужное.
   TormozIT
 
9 - 10.06.21 - 18:41
Читай про объектный кеш https://its.1c.ru/db/pubdevguide83/content/285/hdoc/_top/объектный%20кеш
можно сразу с конца статьи
   TormozIT
 
10 - 10.06.21 - 18:43
(8) Не всегда. Если объект уже есть в объектном кеше, то выгоднее его взять оттуда.
   TormozIT
 
11 - 10.06.21 - 18:47
Слабое место объектного кеша - неполезные большие табличные части, строки неограниченной длины и большие хранилища значений. Из-за них объектный кэш может довольно быстро переполняться и начинается частое вытеснение из него, которое может драматически снижать это положительный эффект (в отрицательную сторону =)
   Злопчинский
 
12 - 10.06.21 - 18:51
(6) то есть если получать реквизиты через ссылку - то получаем при потоврном обращении к другому реквизиту по ссылке спустя короткое время - устаревшее значение? или при оьращении по ссылке проверяется "акутальность" ссылки?
   masenshi
 
13 - 10.06.21 - 18:52
(10) если объект каждый раз новый то всегда а если нет то по ситуации. Но судя по теме надо юзать запрос.
   Сурьма
 
14 - 10.06.21 - 18:58
(4) Если у тебя уже есть объект, то однозначно использовать объект. А если ты хочешь сначала получить объект, то лучше (1)
   ДенисЧ
 
15 - 10.06.21 - 19:07
(12) Не устаревшее. А новое обращение в БД.
   Злопчинский
 
16 - 10.06.21 - 21:07
(15) ну ты ж сам пишешь в (6) - "другого обращения к БД не будет"
..?
   BeerHelpsMeWin
 
17 - 10.06.21 - 21:29
(16) если кто-то обновил реквизит - значит другое обращение к БД уже было
   Злопчинский
 
18 - 10.06.21 - 21:49
(17) а откуда мой сеанс знает что кто-то в другом сеансе обновил реквизит у объекта?
   Вафель
 
19 - 10.06.21 - 22:02
(16) кэш обновляется при записи объекта в любом сеансе, каждый раз проверять валидно6 смысла нет
   Ненавижу 1С
 
20 - 10.06.21 - 22:17
При работе с реквизитами объекта не происходит обращение к бд, но данные могут быть неактуальными.
   mikecool
 
21 - 11.06.21 - 00:43
мнения расходятся )
   Злопчинский
 
22 - 11.06.21 - 00:46
(19) а откуда кэш обьекта знает что ему обновиться надо: или при обновлении обьекта в одном из сеансов - база(сервер) пушем ПО ВСЕМ СЕАНСАМ где есть кэщ этого объекта производит принудительное обновление этого кеша? как это вообще работает?
   Ненавижу 1С
 
23 - 11.06.21 - 00:49
а если обновил реквизит (записал в базе), но в транзакции, которая откатилась?
а если записал в транзакции, но другие то не должны видеть изменений, до коммита?
   DimVad
 
24 - 11.06.21 - 04:53
Ну вот Вы изменили реквизит объекта но не записали объект. Считываете - получаете изменённое значение. Значит данные из памяти.
P.s. Так можно проверить был ли изменён реквизит - сравнить Объект.МойРеквизит с результатом запроса.
   Злопчинский
 
25 - 11.06.21 - 14:01
В итоге - нихрена не понятно.
   Вафель
 
26 - 11.06.21 - 14:02
(22) сервер не дурак - он знает о всех своих сеансах
   Малыш Джон
 
27 - 11.06.21 - 14:05
(25) https://its.1c.ru/db/pubdevguide83#content:303:hdoc

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

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

Если окажется, что версии данных не совпадают (т. е. произошло изменение данных в базе данных), данные, находящиеся в кеше, будут удалены из него, и будет выполнено повторное считывание данных из базы данных. Начиная с этого момента, идет отсчет следующего 20-секундного интервала валидности этих данных.

Кроме всех вышеперечисленных событий считанные данные будут удалены из кеша по истечении 20 минут после их последнего считывания из базы данных.
   Злопчинский
 
28 - 11.06.21 - 14:09
(27) в итоге, если в 20-секундном интервале какая-то другая сессия изменит данные в базе, то я в моей сессии в рамках этого 20-и секундного интервала получу невалидные данные по объекту, так?
   Вафель
 
29 - 11.06.21 - 14:10
Ну и вообще откуда данные что у каждого сеанса свой кэш
   Вафель
 
30 - 11.06.21 - 14:13
(28) ты просто пытаешься смоделировать работу кэша на языке 1с. Но этого конечно не получится
 
 
   fisher
 
31 - 11.06.21 - 14:14
(0) Понимаешь правильно, а чтобы дать совет по правильной организации работы нужно больше инфы по этой самой "работе". Если уже объект был получен для каких-то других целей - то ессно удобно брать данные из него, раз они уже под рукой. Если же речь просто про минимизацию обращений к БД - то обычно выбирают нужную инфу запросами и кэшируют. Кэшировать через объекты может быть очень расточительно, т.к. вычитываются все реквизиты и табличные части.
   Злопчинский
 
32 - 11.06.21 - 14:15
(29) в (28) не ставится вопрос о разные или не разные кэши.
   Злопчинский
 
33 - 11.06.21 - 14:16
(29) в (28) простой тупой вопрос.
   Вафель
 
34 - 11.06.21 - 14:18
(32) в чем проблема при записи объекта сказать серверу чтоб он удалил его из кэша (всех кэшоов если их много)
   Вафель
 
35 - 11.06.21 - 14:19
Ну а на твой вопрос: в кэше всегда последняя версия
   Злопчинский
 
36 - 11.06.21 - 14:19
(34) я ничего не записываю.
   Малыш Джон
 
37 - 11.06.21 - 14:21
(28) да, всё верно ¯\_(ツ)_/¯
   Злопчинский
 
38 - 11.06.21 - 14:21
(35) нестыкоывка.
"Если интервал превысил 20 секунд, будет выполняться проверка на соответствие версии данных, хранящихся в кеше, версии данных, находящихся в базе данных."
- если в кеше всегда последняя актуальная версия - зачем "будет выполняться проверка.."..?
   timurhv
 
39 - 11.06.21 - 14:22
(28) если оперируем ДокументОбъект, то нужно ставить блокировку и тогда никто не сможет изменить документ во время выполнения нашей операции. А если не сможем ее установить, то и обрабатывать смысла нет, т.к. при записи получим ошибку.
   Злопчинский
 
40 - 11.06.21 - 14:22
(37 нестыковка с (35)
   Вафель
 
41 - 11.06.21 - 14:23
Да получается я не верно прочитал, вернее не читал конечно, но думал что в 1с нормальные проги
   Малыш Джон
 
42 - 11.06.21 - 14:24
(40) у меня нет цели стыковать описание механизма работы кэша с мнением всех форумчан)
   Вафель
 
43 - 11.06.21 - 14:30
Сделайте кто-нибудь тест на тему
   Злопчинский
 
44 - 11.06.21 - 14:31
(42) угу. а то ты из себя некотоые спецов строят.. ;-)
В итоге - если не предпринимать спецдействий - есть шанс получить невалидное значение из кеша.

Вопрос77: я правильно понимаю, что в 8-ке наверное есть возможности получить валидное значение не блокируя объект на изменение, типа перечитав актуальное значение объекта?
   Малыш Джон
 
45 - 11.06.21 - 14:32
(44)>>в 8-ке наверное есть возможности получить валидное значение не блокируя объект на изменение

запрос же))
   Злопчинский
 
46 - 11.06.21 - 14:36
(45) а без запроса?
если нужен объект целиком а в объкте стотыщ реквизитов - все перечислять в запросе?
   acht
 
47 - 11.06.21 - 14:36
(39) Транзакции хватит.
Там два объектных кэша - обычный и транзакционный. В документации по ссылке из (9) все написано.
   acht
 
48 - 11.06.21 - 14:38
(46) "*"
   Малыш Джон
 
49 - 11.06.21 - 14:42
(46)

Прочитать (Read)
Синтаксис:

Прочитать()
Описание:

Считывает данные элемента справочника из базы данных.

Доступность:

Сервер, толстый клиент, внешнее соединение, мобильное приложение(сервер).
Примечание:

Позволяет прочесть данные заново. Недопустим для нового объекта.
Пример:

Объект.Прочитать();
   Малыш Джон
 
50 - 11.06.21 - 14:43
хотя настолько глубоко работу кэша я не копал
   fisher
 
51 - 11.06.21 - 14:43
(44) > В итоге - если не предпринимать спецдействий - есть шанс получить невалидное значение из кеша.
Только вне транзакции и тогда это обычно несущественно.
   Злопчинский
 
52 - 11.06.21 - 14:50
(51) фу, какая гадость.
значит мне для гарантированного актуального значения надо дергать запросом непосредственно перед использованием или накладывать транзакцию, которая может быть длинной... фу какая гадость.
остается только дергать запросом, просто так актуализировать объект возможности нет.
   ДенисЧ
 
53 - 11.06.21 - 14:52
(52) А что, актуализация объекта (тм) может происходить без запроса к бд?
   Злопчинский
 
54 - 11.06.21 - 14:54
(53) запрос (обращение к БД) понятно что при аткуализации будет.
получается что в 8-ке актуализировать объект в основном запросом (конструкцией языка) приходится, так?
   Никулин Леонид
 
55 - 11.06.21 - 14:56
(0) Объект для записи. Ссылка для чтения. А оптимальнее читать значения реквизитов запросом. P.S. Если не планируешь записывать, а только читать данные не нужно получать объект.
   ДенисЧ
 
56 - 11.06.21 - 14:59
(54) А где это не так?
   fisher
 
57 - 11.06.21 - 15:00
(52) Где гадость? Если ты не блокируешь прочитанную инфу явно или неявно, то ни в какой момент времени у тебя не может быть уверенности в ее актуальности. Но такая уверенность обычно нужна только в транзакции, а там все Ок. Это справедливо для любых систем.
   Злопчинский
 
58 - 11.06.21 - 15:12
запись не требуется.
только чтение данных.
см. (5), (6), (12), (15)
.
допустим я через ссылку обращаюсь к одному и тому же реквизиту в моменты времени Т1 и Т2, и между Т1 и Т2 данные в базе изменены (значение реквизита изменено) - в момент времени Т2 - я получу неактуальное значение, устаревшее (если между обращениями менее 20 сек)..? так?
   ДенисЧ
 
59 - 11.06.21 - 15:13
(58) В файловой - вероятно, можешь
   fisher
 
60 - 11.06.21 - 15:18
(58) Так. Но приведи мне пример, когда это может стать проблемой.
Мне приходит в голову только какие-то обработки, когда вне транзакции читаются данные и тут же принимается решение об их изменении. Тогда объектный кэш действительно может увеличить вероятность проблем. Мол какой-то объект успели изменить и по нему было принято неверное решение. Но это такое... Такие обработки обычно не совмещают с активным изменением данных. Плюс объектная техника для чтения данных в 8-ке это исключение, а не правило.
 
 
   fisher
 
61 - 11.06.21 - 15:23
При этом платформа не даст изменить объект, состояние которого изменилось с момента чтения. То есть надо достаточно извратиться, чтобы нарыть себе в этом месте неудобство.
   Злопчинский
 
62 - 11.06.21 - 15:27
(60) в 5-6-12-15 - там даже про объектную технику не шло речи. изначально - про работу с реквизитами через ссылку. далее сказано что при дергании реквизита через ссылку - читается весь объект (это объектный кэш? или что?). ну а далее плавно перешло к обсуждению актуальности данных этого _неявно_ считанного по ссылке.реквизиту объекте...
   Злопчинский
 
63 - 11.06.21 - 15:28
(59) то есть в скульной и файловой базе поведение по выдаче данных - будет разное?
   Злопчинский
 
64 - 11.06.21 - 15:29
(61) это понятно, здесь вопросов нет.
   ДенисЧ
 
65 - 11.06.21 - 15:29
(63) Не в скульной, а в серверной.
   Злопчинский
 
66 - 11.06.21 - 15:30
(60) "Такие обработки обычно не совмещают с активным изменением данных."
а не надо изменять данные. достаточно того, что на основании неактуального значения будет принято неверное "решение"
   Злопчинский
 
67 - 11.06.21 - 15:30
(65) согласен с уточнением.
   Никулин Леонид
 
68 - 11.06.21 - 15:30
(58) нет.
Если в коде написано Ссылка.Контрагент ты получишь контрагента1. Потом через секунду контрагент изменился на контрагента2. Еще через секунду прочитать Ссылка.Контрагент ты получишь нового контрагента2. Если каждый раз обращаться именно к базе данных всегда будешь получать актуальные значения. Запусти два сеанса. В одном читай построчно отладчиком, а во втором интерактивно меняй значения. Вот и посмотришь
   Злопчинский
 
69 - 11.06.21 - 15:32
(68) "Если в коде написано Ссылка.Контрагент ты получишь контрагента1. Потом через секунду контрагент изменился на контрагента2. Еще через секунду прочитать Ссылка.Контрагент ты получишь нового контрагента2."
- то есть здесь никакого кэша не используется (правило 20 сек не работает), и "я" получаю всегда актуальные данные? - так?
   fisher
 
70 - 11.06.21 - 15:38
(62) Ты о чем говоришь? О том, что при активном использовании объектного кэша увеличивается вероятность попасть вне транзакции на рассогласование прочитанных данных? Да.
Но никакого ужаса тут нет. Вполне понятный и оправданный трейдофф.
   fisher
 
71 - 11.06.21 - 15:42
Да и вообще все эти неявные обращения через точку протащили на правах совместимости, потом замутили кэш чтобы сгладить проблему производительности... Проще было бы сразу забанить. Все равно по итогу обращения через точку считаются моветоном и при хорошем стиле почти не используются.
   Злопчинский
 
72 - 11.06.21 - 15:43
(70) угу. и это понятно.
   Злопчинский
 
73 - 11.06.21 - 15:44
(70) а по (69)..? из сказанного в (68) следует что при использовании Ссылка.Реквизит - я всегда получаю  актуальные данные, то есть кэш здесь не работает. в (68) правильно изложено?
   fisher
 
74 - 11.06.21 - 15:46
(71) + Ну или не кэшировать объект при первом обращении через точку, а фигачить точечный запрос.
Вот это вот полное кэширование объекта при первом обращении через точку - пипец неявная засада производительности.
(73) Не. В (68) неправильно.
   Злопчинский
 
75 - 11.06.21 - 15:52
(74) "в (68) неправильно".
.
я в ахуе.
.
специалисты по 80ке, блин.
.
(68) - говорит что правильно, (74) что неправильно.
.
есть тут еще специалисты? или так, галкорасставлятели только?
   fisher
 
76 - 11.06.21 - 15:53
(75) Хотя... Надо протестить. Что-то мне не верится, что в УФ в клиент-серверной для каждой сессии заводится отдельный кэш. Как-то это глупо. А единый кэш вообще не проблема при записи сбрасывать.
Да, вот такие специалисты собрались :)
   Garykom
 
77 - 11.06.21 - 15:55
(76) есть и кэш сессии и общий кэш конфы/базы
   Злопчинский
 
78 - 11.06.21 - 15:56
ну так правильно в (68) или нет...?
специалисты-погромисты...
   fisher
 
79 - 11.06.21 - 15:58
(77) А зачем в случае клиент-сервера и УФ? Это же кэши одинакового уровня будут.
   Garykom
 
80 - 11.06.21 - 15:58
(78) нет (58) не так
   fisher
 
81 - 11.06.21 - 15:59
(78) Это только семерочникам критично. Спецам по восьмерке использовать объектный кэш - моветон :)
   Garykom
 
82 - 11.06.21 - 16:00
(79) специфические области видимости
если объект доступен только конкретной сессии нет смысла класть его в общий кэш да еще с привязкой к конкретной сессии чтобы разделять доступ/имя
   Злопчинский
 
83 - 11.06.21 - 16:01
(80) это как?
ты говоришь, что в (68) - изложено неверно.
при этом ты говоришь что "(58) не так" - то есть _отрицаешь_ вопрос что я получу неактуальное значение.
вообще ничего не понял тогда
   fisher
 
84 - 11.06.21 - 16:02
(82) Логично. И тогда при записи поиск в сессионных кэшах не делается из соображений производительности, так что ли?
   Никулин Леонид
 
85 - 11.06.21 - 16:02
При чем здесь восьмерка или семерка? Поведение одинаковое будет при обращении через точку и в семерке, и в восьмерке. Каждое обращение через точку это новый запрос к базе данных, а не чтение кэша. Нет разницы через 20 секунд , раньше или позже.
   Злопчинский
 
86 - 11.06.21 - 16:04
Мнения разделились.
неквалифицирован либо Никулин Леонид либо Garykom ибо утверждают противоположное.
   fisher
 
87 - 11.06.21 - 16:04
(84) + Отвечу сам себе. Наверное, так. Ведь сессии могут быть разбросаны по разным серверам.
   arsik
 
88 - 11.06.21 - 16:05
(1) >Через ОбщегоНазначения.ПолучитьРеквизитыОбъекта(), разумеется
Доколе. Когда уже сделают встроенную функцию.
   fisher
 
89 - 11.06.21 - 16:05
(86) Там вверху была ссылка на ЖКК, которой Никулин противоречит. Изложенное в ЖКК по итогу звучит логично. А проверять лень даже тебе.
   Garykom
 
90 - 11.06.21 - 16:08
(86) прочитай внимательно (58)
а затем слово "нет" в (68) и (80)
   Garykom
 
91 - 11.06.21 - 16:09
(89) мы совсем на другой вопрос отвечали
   fisher
 
92 - 11.06.21 - 16:10
(91) Если твой ответ на (58) "нет" верен, то для этого должна происходить синхронизация всех сессионных кэшей при записи.
   fisher
 
93 - 11.06.21 - 16:11
В части инфы по записываемому объекту
   Garykom
 
94 - 11.06.21 - 16:12
(92) естественно
зачем нужен кэш с неактуальными данными? понятно дело есть механизм отслеживания протухания кэша и следующее обращение дернет базу а не старье из кэша
   Злопчинский
 
95 - 11.06.21 - 16:14
(85) "Поведение одинаковое будет при обращении через точку и в семерке, и в восьмерке. Каждое обращение через точку это новый запрос к базе данных, "
- в части 77 - утверждение неверное.
СпрН.Производитель и СпрН.ТекущийЭлемент().Производитель - дадут разные значения.
   Garykom
 
96 - 11.06.21 - 16:14
(94) а если механизм не сработал будут разные прикольные глюки как часто довольно бывает
когда рекомендация почистить кэш помогает
   Злопчинский
 
97 - 11.06.21 - 16:15
(89) я проверить не могу. я по 8-ке только юзер, а не прог.
поэтому - как тест - вот я юзер. и кому мне верить..?
тут блин все спецы восьмерочные...  такие.. спецы...
   Garykom
 
98 - 11.06.21 - 16:15
(95) ты не путай разные значения до записи в базу, когда одно уже поменяли
   fisher
 
99 - 11.06.21 - 16:16
(94) То есть по ссылке в (9) чушь собачья?
"При повторном обращении к кешу за данными уже считанного объекта будет анализироваться интервал времени, прошедший с момента появления данных в кеше.
Если обращение происходит в пределах 20 секунд после поступления данных в кеш, данные считаются верными (валидными). Если интервал превысил 20 секунд, будет выполняться проверка на соответствие версии данных, хранящихся в кеше, версии данных, находящихся в базе данных"
   Злопчинский
 
100 - 11.06.21 - 16:17
(98) это мы обсудим позже. так как малость в сторону от основнйо темы по 8-ке
  1  2  3   

Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.