Имя: Пароль:
1C
1С v8
Записать() в процедуре ПередЗаписью()
,
0 Assena
 
07.06.12
10:12
Доброго времени суток, Уважаемые!
Понадобилось мне при записи группы номенклатуры с определенным признаком проставить данный признак у всех элементов группы.
Написала код:

Если НекийПризнак Тогда
           Выборка=Справочники.Номенклатура.Выбрать(ЭтотОбъект.Ссылка);
           Пока Выборка.Следующий() Цикл
               Если Не Выборка.НекийПризнак Тогда                    
                   ЭлементНом=Выборка.ПолучитьОбъект();
                   ЭлементНом.НекийПризнак =Истина;
                   ЭлементНом.Записать();
               КонецЕсли;
           КонецЦикла;                      
       КонецЕсли;

Но смущает меня, что в процедуре ПередЗаписью() снова вызывается запись. Говорят, некошерно.. Посоветуйте что-нить
1 Defender aka LINN
 
07.06.12
10:13
(0) Выкинуть этот копрокод. И признак заодно.
2 Assena
 
07.06.12
10:14
(1) спасибо за дельный совет, а по существу?
3 DrShad
 
07.06.12
10:15
Нафига плодить признак у всех элементов, если его можно по родителю всегда получить
4 unregistered
 
07.06.12
10:15
(0) >> проставить данный признак у всех элементов группы

Зачем?

(1) +100
5 DrShad
 
07.06.12
10:15
(2)по существу - нефига страдать рукоблудием
6 abitfrosty
 
07.06.12
10:15
Рекурсия - см. Рекурсия.
7 Широкий
 
07.06.12
10:17
(0) Выбирай запросом с проверкой на то что признак не установлен..
И я бы поставил в ПриЗаписи - не факт что твой элемент запишется, плюс не понятно что с группами делать
8 Assena
 
07.06.12
10:17
логично.. хотя не очень приветливо((
9 Defender aka LINN
 
07.06.12
10:18
(2) Это и есть по существу. Говнокод - удалить, реквизит выпилить, аффтару дать в руки метлу, может хоть с ней он справится.
10 Assena
 
07.06.12
10:19
Доброго всем утра)) и приятного рабочего дня. Спасибо за советы
11 DrShad
 
07.06.12
10:19
(10) срочно замуж! и детей рожать
12 unregistered
 
07.06.12
10:19
(7) >> И я бы поставил в ПриЗаписи

За такое табуреткой по пальцам.
Если в ПриЗаписи изменять реквизиты объекта, то будет повторно вызываться обработчик ПередЗаписью.
13 Assena
 
07.06.12
10:20
опытные программисты все такие Злобные Тролли?
14 Assena
 
07.06.12
10:21
(11) моему сыну уже 22 года, скоро бабушкой стану))
15 Defender aka LINN
 
07.06.12
10:23
(12) Ты из принципа только сабж читаешь, (0) скрыт скриптом?
(13) Это мы по-доброму. Ну не создана ты для программирования, что поделать.
16 Широкий
 
07.06.12
10:26
(12) По голове табуреткой себе постучи. Текущий элемент не меняется - меняются тока подчиненные
17 Avganec
 
07.06.12
10:30
(0) Такие вещи надо убирать из записи, хотя бы просто по причине блокировок. Надо просто логику поменять, а код... на край можно оставить даже таким... но опять таки, с проверкой на запись...
18 Assena
 
07.06.12
10:32
(17) об этом я и подозревала)) спасибо
19 Широкий
 
07.06.12
10:35
(17) Какие еще блокировки? Подчиненный элемент записался - блокировка на этот элемент снялась (ессно управляемый режим блокировок скульный вариант)
20 Avganec
 
07.06.12
10:40
(19) Блокировка на то, что данный элемент кто-то открыл и правит.
21 Avganec
 
07.06.12
10:40
(18) не за что...
22 Широкий
 
07.06.12
10:44
(20) почитай про оптимистическую/пессимистичкие блокировки. Если юзер откроет элемент - обработка все равно запишет свои данные
23 Avganec
 
07.06.12
10:45
(22) Люблю учиться. Если кинешь правильный линк на такую вещь - только спасибо скажу.
24 unregistered
 
07.06.12
10:45
(15) >> Ты из принципа только сабж читаешь, (0) скрыт скриптом?

Что не так? Я где-то не прав?
25 Широкий
 
07.06.12
10:49
26 unregistered
 
07.06.12
10:49
(16) >> Текущий элемент не меняется - меняются тока подчиненные

Какая разница меняется он или нет? Он записывается.

В обработчике ПриЗаписи у первого же элемента из выборки в этом цикле ты собрался менять како-то поле. У этого элемента (который уже как раз меняется) обработчик ПриЗаписи по-твоему не будет выполняться?
27 Широкий
 
07.06.12
10:52
(26) Будет. Развивай мыслю дальше
28 Avganec
 
07.06.12
10:53
(25) Хорошо, давай рассмотрим ситуацию, когда от пользователя идет запись элемента и из обработки идет запись элемента, абсолютно одновременно, ну или от пользователя по-раньше. В этом случае проверку на блокировки тоже не надо делать?
29 stix2010
 
07.06.12
10:54
(0) на...ра все это? подобные вещи в регистре сведений надо держать
30 Avganec
 
07.06.12
10:55
(29) это вопрос к хранению данных, в некоторых случаях да, в некоторых нет.
31 Широкий
 
07.06.12
11:01
(28) Где предлагаешь делать проверку - у обработки или у юзерпа?
32 Avganec
 
07.06.12
11:04
(31) у юзера выкинеться ошибка, и он еще раз нажмет на кнопочку, а вот обработка вылетит...
33 dmpl
 
07.06.12
11:05
(3) Дык а если в этой группе будет еще группа?
34 Широкий
 
07.06.12
11:06
(32) Обработка не остановится
35 Avganec
 
07.06.12
11:08
(33) В таком случае найдется группа, и для нее выполниться этот же код по подгруппе...
36 Avganec
 
07.06.12
11:08
(34) без проверки - вылетит... выдаст ошибку на запись. разве нет?
37 Широкий
 
07.06.12
11:12
(36) Повторяю: нет, не вылетит.
38 artbear
 
07.06.12
11:13
(0) Почти Нормальный код, только его нужно перенести в ПриЗаписи и добавить в цикл строку
ЭлементНом.ОбменДанными.Загрузка = Истина;
39 Avganec
 
07.06.12
11:15
(37) объясни. Обработка выполняет запись, запись неудачна - есть блокировка, в коде обработки нет - все. Если ты говоришь про грамотный код, то я с тобой согласен, но в общем случае - нет.
40 unregistered
 
07.06.12
11:16
(27) Что развивать?

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

Вообще обсуждать нечего. В (0) авнокод.
Таких вещей не следует делать не в ПриЗаписи не в ПередЗаписью.

Даже если действительно надо обязательно установить значение некоего свойства для каждого элемента по иерархии (хотя это всегда можно получить запросом, когда нужно), то для этого можно использовать регистр сведений (в том числе типовой ЗначенияСвйств).
При записи группы получить запросом все подчиненные элементы и установить значение ресурса регистра сведений для каждого измерения - номенклатура.

Но придется еще контролировать момент переноса элемента из одной группы (где устанавливаемое свойство имеет одно значение) в другую группу (где это свойство может иметь другое значение).
41 Defender aka LINN
 
07.06.12
11:17
(26) Какбе в (0) же ж русским по желтому написано, ЧТО записывается.
(38) Да нихрена нормального там нет. В номенклатуре ссылка на номенклатурную группу, в ней есть реквизит, для нахрена денормализацией заниматься?
42 Широкий
 
07.06.12
11:21
(39) Да блин.. объектная пессимистическая блокировка (юзер открыл элемент справочника) на обработку не будет распространяться, только на интерактивные действия других юзеров.
43 Avganec
 
07.06.12
11:23
(42) так я тебе не про это, а про запись непосредственную уже.
44 Широкий
 
07.06.12
11:26
(40)
"В ПриЗаписи поменяли реквизит.
Повторно вызывается обработчик ПередЗаписью, потом опять ПриЗаписи (теперь уже ни чего не меняется). "  
С какого перепуга? Данный элемент уже не меняется, признак и так установлен. Меняются ПОДЧИНЕННЫЕ элементы.
45 Assena
 
07.06.12
11:36
(38) так и сделала, ибо ошибка как раз при обмене возникала..
(41) я понимаю, что код кривой, иначе бы не обратилась за помощью, а че.. работает типа и так сойдет.. Но я так и не услышала дельного совета, как бы вы поступили, если бы надо было при записи группы с определенным признаком проставить этот признак у всех подчиненных (а там действительно есть еще и подгруппы и использовать признак родителя не получится)
46 Широкий
 
07.06.12
11:39
(45) Зачем полную иерархию делать? Достаточно выбрать только в пределах непосредственно подчинения а дальше группы сами перезапишут свои подгруппы
47 artbear
 
07.06.12
11:40
(41) хорошо, представим, признак хранится у группы, далее в запросе нужно отобрать элементы по этому признаку.
В результате будем запускать тормознейший код через "В ИЕРАРХИИ(...)" ??
как раз для исключения подобных иерархических запросов лучше юзать признак в самом объекте или хотя бы регистр сведений.
ЗЫ поэтому, например, 1С настройки прав для RLS хранит для каждого элемента справочника, а не по группам :)
48 artbear
 
07.06.12
11:41
(45) если есть подгруппы, тогда вместо программной выборки нужно юзать запрос, используя "В Иерархии(&Ссылка)" и все :)
49 Avganec
 
07.06.12
11:42
(45) Если вы хотите хороший код, то тогда надо развернуть задачу. Понять можно ли под хранение использовать регистр сведений, или нельзя. После этого уже можно и над самим кодом подумать.
50 unregistered
 
07.06.12
11:49
(44) Вызов происходит рекурсивно. Отладчик запусти, если слов не понимаешь.
51 ТеньПустоты
 
07.06.12
11:51
(0) ты не горячись. из 50ти ответов как минимум 2 ббудут ползными. а трололошей тут очень много
52 artbear
 
07.06.12
11:52
(50) Условия задачи почитай и запускай отладчик, если по условиям непонятно :(
53 artbear
 
07.06.12
11:52
(41) Жду ответа на (47)
54 unregistered
 
07.06.12
11:58
(53) А чего ждать. Да ты прав. Только это не означает, что код в (0) становится правильным.
55 unregistered
 
07.06.12
11:58
(52) Что именно тебе непонятно в условиях задачи? :)
56 Широкий
 
07.06.12
12:07
(50) Эко как тебя переклинило
57 unregistered
 
07.06.12
12:28
(16) (27) (52) (56) Извиняюсь, разобрался. (вот я дебил... как-то некрасиво получилось)

PS Но я все равно за регистр сведений. :)
58 dmpl
 
07.06.12
14:05
(35) В запросе то? Ай, фантазер!
59 artbear
 
07.06.12
15:20
(0)(45) Ответ из (48) понятен? проблема решена?
60 Mort
 
07.06.12
15:25
То что пометка удаления группы аналогично помечает (и, соответственно, записывает) дочерние элементы почему-то никого не возбуждает.
61 artbear
 
07.06.12
18:22
(60) Хорошее замечание.
1. Но в контексте текущей задачи эта проблема несущественна.
В запросе "В Иерархии(...)" будет стоять условие по этому признаку и будут выбираться и перезаписываться только те элементы, у которых признак еще не установлен.
Кстати, забыл сказать (0), чтобы уходила от Спр.Выбрать к запросу по иерархии и условием по неравенству признака или его незаполненности :)
2. ИМХО если группа специально помечается на удаление, она уже не так нужна :)