Как сделать запрос на изменение данных

Программирование - Практика программирования

59
В статье приведены особенности внутренней архитектуры и примеры работы с расширением языка запросов 1С.

Само расширение объединенное с консолью запросов лежит тут.

Как я до этого докатился.

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

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

Ответом на все эти вопросы стало понимание того факта, что есть две разные сущности, которые стоит рассматривать изолированно друг от друга:

  • объект системы, полученный по ключам (ДокументОбъект, Набор записей) и ключи получения этого объекта (ссылка для объекта, значения измерений для рс...)
  • редактируемый объект (напр. табличная часть) и ключи редактирования объекта (напр. ссылка и номер строки для таб.части)

И после того, как был написан движок, редактирующий объекты таким образом - метод редактирования: из динамического списка или запросом ИЗМЕНИТЬ - уже дело техники.

Так как же это работает.

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

Текст каждого запроса парсится. Запросы, начинающиеся со слова "ВЫБРАТЬ" оставляются как есть. Запросы начинающиеся со слов УДАЛИТЬ или ИЗМЕНИТЬ преобразуются к виду ВЫБРАТЬ. Из них извлекается имя таблицы и условие ГДЕ, далее к этому добавляется фраза "ВЫБРАТЬ " с перечислением тех самых ключей редактирования объекта и полученный текст вставляется в большой запрос. Например, таким образом из запроса:

|ИЗМЕНИТЬ Справочник.Номенклатура
|УСТАНОВИТЬ Код = "001"
|ГДЕ Ссылка В (&МассивСсылок)

получится запрос:

|ВЫБРАТЬ Ссылка, "001"
|ИЗ Справочник.Номенклатура
|ГДЕ Ссылка В (&МассивСсылок)

При этом в специальной структуре запоминается, что запрос номер такой-то - это больше чем просто запрос.

В генерируемую фразу ВЫБРАТЬ вставляется кроме прочего еще все значения, присваиваемые полям во фразе УСТАНОВИТЬ. Это нужно, чтобы при появлении сложных значений, типа значений параметров, значений через точку и так далее, запрос вычислил их значения за нас.

Далее, полученный текст запроса выполняется штатным объектом Запрос.

Далее, по результатам запросов, тексты которых были преобразованы начинается магия:

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

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

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

Все изменения выполняются в транзакции и в режиме обмена данными.

Дополнения, замечания:

  1. Предлагаемый метод изменения данных безопасен. При нем отработают все подписки, проверки, регистрация на планах обмена и т.д. и т.п.
  2. Предлагаемый метод изменения данных близок к оптимальному по производительности (насколько это возможно в объектной модели) во всех случаях, кроме одного: если условия изменения данных в регистре сведений, не подчиненном регистратору позволяют производить чтение/запись с отбором не по всем измерениям. Думаю, тут есть простор для оптимизации, но пока все работает как работает.
  3. В части чтения данных, создания временных таблиц и т.д. и т.п. можно писать сколь угодно "тяжелые" запросы.
  4. В части ИЗМЕНИТЬ, УСТАНОВИТЬ, УДАЛИТЬ ИЗ и ВСТАВИТЬ В следует придерживаться строгих правил и не пытаться креативить.
  5. Если имеет место пакет из, например, 3-х запросов, 1-й читает, 2-й изменяет, 3-й перечитывает данные - то в результате 3-го запроса будут получены еще не измененные данные.
  6. Попытка изменить данные будет либо полностью удачной либо полностью неудачной для всех запросов.
  7. Конструктор запросов, понятное дело, все это буйство фантазии не переварит.

Важно!

"Особые поля" пока никак не обрабатываются. Если вы попытаетесь изменить реквизит ИмяПредопределенныхДанных или ЭтоГруппа или значение измерения регистра сведений - это приведет к исключению.

Тут опять же большой простор для действий напильником, но пока все так как есть.

Что можно писать во фразе ИЗМЕНИТЬ

В этой фразе пишется имя таблицы, которую предстоит изменить. Только имя первичной таблицы. (здесь и далее под "первичной" будет пониматься не агрегатная, не виртуальная, а "простая" таблица) Например:

  • Справочник.Номенклатура
  • Документ.ПоступлениеТоваровУслуг.Товары
  • РегистрСведений.ЦеныНоменклатуры
  • РегистрНакопления.ТоварыНаСкладах

Никаких ...Остатки(), ...СредПоследних() и т.п. быть не должно

Что можно писать во фразе УДАЛИТЬ ИЗ

Правила аналогичны правилам фразы ИЗМЕНИТЬ.

Что можно писать во фразе УСТАНОВИТЬ

В этой фразе перечисляются поля таблицы, которые необходимо изменить и значения, которые они должны принять. Например:

  • Наименование = "Новое наименование"

При установке значений нескольких полей они разделяются запятыми, например:

  • ЕдиницаИзмерения = &МояЕдиница, Код = Артикул, ИспользованиеХарактеристик = ВидНоменклатуры.ИспользованиеХарактеристик

В качестве значения можно использовать любое значение, которое может быть вычислено во фразе "ВЫБРАТЬ". т.е. строки, числа, значения реквизитов, значения "через точку", ВЫБОР КОГДА... значение параметра запроса.

Что можно писать во фразах запроса ВСТАВИТЬ

Запрос ВСТАВИТЬ является наиболее сложным с точки зрения реализации. Дело в том, что во-первых вставлять данные чуть сложнее, чем изменять существующие (в одном случае объект надо создать, в другом просто получить и добавить строку в тч, плюс группы справочников) во-вторых хотелось сделать инструкцию ВСТАВИТЬ более вариативной: вставлять как какие-то конкретные значения, так и полученные запросом.

Если данные получаются запросом - описание полей не требуется, а вставляемые значения будут сопоставлены с полями таблицы по именам. Схема запроса в этом случае такая:

ВСТАВИТЬ В
    [ИмяТаблицы]
ЗНАЧЕНИЯ
    (ВЫБРАТЬ ...),
    (ВЫБРАТЬ ...),
    ...

Если данные вставляются конкретными значениями - требуется описание полей:

ВСТАВИТЬ В
    [ИмяТаблицы] ([ИмяПоля1], [ИмяПоля2] ...)
ЗНАЧЕНИЯ
    ([Значение1], [Значение2] ...),
    ([Значение1], [Значение2] ...),
    ...

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

При вставке нескольких наборов действует жесткое правило: количество и порядок полей должны быть одинаковые. Это требуется, поскольку запрос ВСТАВИТЬ на первом этапе, так же как и в других случаях, преобразуются к запросу ВЫБРАТЬ, а вернее к их объединению (ОБЪЕДИНИТЬ ВСЕ).

При добавлении записей в "объектные таблицы", при наличии поля "Ссылка" - в нем должны быть указаны строковые представления уникальных идентификаторов, уникальные идентификаторы или ссылки соответствующего типа. Создаваемым объектам будут присвоены соответствующие ГУИДы

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

Некоторые примеры

Попробуем решить задачу: заполнить реквизит ИспользованиеХарактеристик номенклатуры по соответствующему значению вида номенклатуры. Заполнять только незаполненные.

Способ 1:

|ВЫБРАТЬ Номенклатура.Ссылка
|ПОМЕСТИТЬ ВТСсылкиНоменклатуры
|ИЗ Справочник.Номенклатура КАК Номенклатура
|ГДЕ Номенклатура.ИспользованиеХарактеристик = ЗНАЧЕНИЕ|(Перечисление.ВариантыИспользованияХарактеристикНоменклатуры.ПустаяСсылка)
|;
|ИЗМЕНИТЬ Справочник.Номенклатура
|УСТАНОВИТЬ ИспользованиеХарактеристик = ВидНоменклатуры.ИспользованиеХарактеристик
|ГДЕ Ссылка В (ВЫБРАТЬ Ссылка Из ВТСсылкиНоменклатуры)

Способ 2:

|ИЗМЕНИТЬ Справочник.Номенклатура
|УСТАНОВИТЬ ИспользованиеХарактеристик = ВидНоменклатуры.ИспользованиеХарактеристик
|ГДЕ ИспользованиеХарактеристик = ЗНАЧЕНИЕ(Перечисление.ВариантыИспользованияХарактеристикНоменклатуры.ПустаяСсылка)

Способ 3:

|ИЗМЕНИТЬ Справочник.Номенклатура
|УСТАНОВИТЬ ИспользованиеХарактеристик = ЗНАЧЕНИЕ(Перечисление.ВариантыИспользованияХарактеристикНоменклатуры.НеИспользовать)
|ГДЕ ИспользованиеХарактеристик = ЗНАЧЕНИЕ(Перечисление.ВариантыИспользованияХарактеристикНоменклатуры.ПустаяСсылка) И ВидНоменклатуры.ИспользованиеХарактеристик = ЗНАЧЕНИЕ(Перечисление.ВариантыИспользованияХарактеристикНоменклатуры.НеИспользовать)

Способ 4:

|ИЗМЕНИТЬ Справочник.Номенклатура
|УСТАНОВИТЬ ИспользованиеХарактеристик = ВидНоменклатуры.ИспользованиеХарактеристик
|ГДЕ Ссылка В (ВЫБРАТЬ Ссылка ИЗ Справочник.Номенклатура ГДЕ ИспользованиеХарактеристик = ЗНАЧЕНИЕ(Перечисление.ВариантыИспользованияХарактеристикНоменклатуры.ПустаяСсылка))

Разные способы приведены для демонстрации вариантов написания запроса с использованием расширения, не нужно воспринимать их как образец "правильности" и производительности.

Задача: Заменить Характеристику1 на Характеристику2 в остатках товаров

|ИЗМЕНИТЬ РегистрНакопления.ТоварыНаСкладах
|УСТАНОВИТЬ Характеристика = &Характеристика2
|ГДЕ Характеристика = &Характеристика1

Важно уточнить, что в этом случае таблицы остатков будут пересчитаны платформой автоматически

Задача: Во всех поступлениях с начала этого года изменить цену Номенклатуры1 с 500 на 700 рублей

|ИЗМЕНИТЬ Документ.ПоступлениеТоваровУслуг.Товары
|УСТАНОВИТЬ Цена = 700, Сумма = 700*Количество
|ГДЕ Ссылка.Дата > &ДатаНачалаЭтогоГода И Номенклатура = &Номенклатура1 И Цена = 500

В этом же случае, ничего кроме изменения самой цены (и суммы) не произойдет, поскольку запись всегда происходит в режиме записи. Сумма документа, Расчеты с поставщиком останутся прежними.

Задача: Добавить в документ товар

Способ 1 (добавление предопределенного товара):

|ВСТАВИТЬ В Документ.РеализацияТоваровУслуг.Товары (Ссылка, Номенклатура, Количество, Цена, Сумма)
|ЗНАЧЕНИЯ (&Документ, Значение(Справочник.Номенклатура.Предопределенная1), 8, 100, 800)

Способ 2 (копирование строки из другого документа):

|ВСТАВИТЬ В Документ.РеализацияТоваровУслуг.Товары
|ЗНАЧЕНИЯ (ВЫБРАТЬ &Приемник, * ИЗ Документ.РеализацияТоваровУслуг.Товары ГДЕ Ссылка = &Источник И НомерСтроки = 1)

 

Теперь вы знаете, как работает мой вариант расширения языка запросов. Можете использовать это знание, чтобы лучше понимать, как с ним обращаться, можете сделать свое расширение с блэкджеком и соединением таблиц при изменении. Главное - не забывайте делиться результатами с сообществом. Удачи!

59

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. CyberCerber 218 01.06.18 10:54 Сейчас в теме
Выглядит круто.
Только я не увидел или пропустил самое главное... Как происходит само изменение данных? Стандартными объектами? Как изменяются регистры сведений, подчиненные регистратору? Удаление данных происходит без контроля ссылочной целостности?
2. m-rv 627 01.06.18 11:16 Сейчас в теме
(1)
само изменение - объектами, да
все регистры - наборами.
удаление - без контроля ссылочной целостности (если только не начнет работать платформенный контроль по ведущим измерениям)
3. Aphanas 126 01.06.18 12:50 Сейчас в теме
Как насчет добавления данных? Что-то не увидел.
4. m-rv 627 01.06.18 13:35 Сейчас в теме
(3) Запрос ВСТАВИТЬ (INSERT) ожидается, следите за обновлениями
7. kote 487 02.06.18 19:55 Сейчас в теме
Самое главное, пожалуйста, скажите - использование этого подхода сильно сокращает количество кода?
Если будет что-то с примерами - вообще шикарно будет.
8. Артано 633 04.06.18 05:12 Сейчас в теме
(7)Сомневаюсь, просто он будет организован по единому образцу, что по эффекту будет сопоставимо.
Вообще язык запросов имеет большой потенциал в плане легкости чтения кода за счет строгого разделения функциональных блоков запроса.
В любом случае лайк.
11. Terve!R 06.06.18 07:48 Сейчас в теме
(8) никакой легкости чтения кода в запросах нет. Ну разве что не использовать вложенные запросы и кучу соединений. Опытный программист конечно любой запрос прочитает, но не потому что там заложен какой-то потенциал.
12. m-rv 627 06.06.18 09:16 Сейчас в теме
(11) довольно спорное утверждение.
понятно, что можно придумать ситуацию, когда чтение данных при помощи объектной модели будет "читаемее" запроса, а можно придумать и обратный пример. да и вообще "читаемость" весьма оценочная категория.
но в некоторых случаях использование объектной модели ведет просто в ад. напишите такое на объектной модели:
ВЫБРАТЬ РАЗЛИЧНЫЕ Ссылка ИЗ Документ.ПоступлениеТоваровУслуг.Товары ГДЕ Номенклатура В (&МассивНоменклатуры)
А в запросе все очевидно.
Dementor; +1 Ответить
9. m-rv 627 04.06.18 08:06 Сейчас в теме
(7) Я на самом деле использую это в качестве консоли, когда, например, "забыли" заполнить обменом какую-нибудь единицу изменения в номенклатуре или типа того, но в целом я согласен с коллегой - в некоторых случаях количество строк сократится (когда, например, не придется вручную перебирать документы для замены номенклатуры в ТЧ), но в основном это скорее про организацию и читаемость кода
13. vec435 15 08.06.18 19:01 Сейчас в теме
запросы на изменения пишутся руками?
14. m-rv 627 09.06.18 07:53 Сейчас в теме
15. vec435 15 10.06.18 16:20 Сейчас в теме
тогда добавь мастера который из запроса вида
выбрать код,наименование из справочник.Номенклатура где ссылка=&ссылка
сделает
ИЗМЕНИТЬ Справочник.Номенклатура
УСТАНОВИТЬ наименование = &параметр1,код=&параметр2
где ссылка=&ссылка
16. acanta 45 18.06.18 13:35 Сейчас в теме
Можно добавить в текст запроса СокрЛП ?
17. ufedor 52 16.07.18 16:50 Сейчас в теме
+ за системный подход!
по моему опыту, процедура обновления часто требуется в соединении. т.е. нужна конструкция вида
Обновить Т1
установить реквизит = значение
из
Т1 внутреннее соединение Т2 по Т1.Ключ = Т2.Ключ
если например значение нужно взять из другой таблицы.
Планируется ли развитие механизма?
18. m-rv 627 17.07.18 07:47 Сейчас в теме
(17) соединения в изменении выглядят весьма заманчиво, согласен, но пока на это нет времени. может быть, когда-нибудь...
19. Darklight 15 28.08.18 17:54 Сейчас в теме
Всё почти хорошо, но вот эти ограничения - всё портят:
1. "изменить ... значение измерения регистра сведений - это приведет к исключению." - нельзя изменять значения в измерениях регистров сведений? Почему?
2. "Если имеет место пакет из, например, 3-х запросов, 1-й читает, 2-й изменяет, 3-й перечитывает данные - то в результате 3-го запроса будут получены еще не измененные данные." Бред. Нужно разделять выполнение пакетных команд. Ведь что мешает выпоонить оставшуюся часть пакета (чтение) после выполнения первой на изменение.Ведь и последующее изменение тоже может быть основано на чтении уже обновлённых данных.
3. Отсутствие поддержки соединений тоже никуда не годится
4. Нужна пакетная вставка в таблицу (NSERT INTO SELECT )

А ещё хочется дополнительные операции вставки для накопительных регистров - на увеличение и уменьшение значения (упрощённый синтаксис - приход, расход) и отдельно на установку заданного значения остатка (типа как инвентаризация).

Ну а пожелание того, чтобы такие запросы ещё можно было бы по фоновым процессам распараллеливать - будет вообще из области фантастики.

Кстати, а как происходит обновление регистров с итогами - нужно какое-то управление из текста запроса, чтобы можно было бы обновлять итоги отдельно - после внесения всех изменений в исходные данные. Я порнима, что это всё можно было бы сделать вне запроса пррогаммно (или интеарактивно), но всё же для консоли удобно - чтобы это было в самом запросе.
20. m-rv 627 29.08.18 08:14 Сейчас в теме
(19) ох.. ну давайте по пунктам:
1. попробуйте взять рс неподчиненный регистратору, прочитайте по какому-нибудь отбору, а потом в наборе измените значение измерения, по которому был установлен отбор. посмотрите на результат. понятно, что это не непреодолимая ситуация: можно один набор удалить, второй записать.. но эти алгоритмы не реализованы.
2. ну вот сейчас так не работает, потомучто это будет работать медленнее. хотя, соглашусь, что можно это вынести как параметр.
3. это без комментариев, попробуйте сами такое реализовать.
4. это есть, читайте внимательнее
5. апдейты агрегатных таблиц - ну бросьте вы, это решается пакетом из 2-х запросов за 5 секунд.
6. параллелизм - смотря для чего: для чтения данных - стоит ли огород городить? для записи - начнутся блокировки, надо как-то потоки разводить по типам объектов, это жутки гемор и уже уровень не беспланой фичи для инфостарта, а энтерпрайзного решения.
7. да, такая мысль у меня тоже проскальзывала, наверно допилю как-нибудь..
21. Darklight 15 29.08.18 10:08 Сейчас в теме
1. Вот я и говорю, не реализованы - плохо - это кучу функционала урезает - задач на изменение измерений РС достаточно много.
2. Интересно, насколько же это модленнее. Я считаю работать должно предсказуемо и удобно, не важно что это будет несколько медленнее, чем через "одно место". Тем более замедление, если и будет заметным, то только в тех случаях, когда пакет действительно будет разделать на части, когда в нём будет обнаружена такая необходимость - а раз такая необходимость будет - то от неё (при использовании) всё-равно никуда не деться - не движку, так вызывающему алгопритму/пользователю придётся думать о таком делении и делить пакет на части - что, согааситесь, неудобно и всё-равно вызовет уменьшение производительности, каким-бы оно ни было заметным (а вот неудобство точно будет замечено).
3. Я не говорю, что это легко, но, без этого всё пока ущербно - буду надеяться на лучшее!
4. Вы вот этот код имели в виду

|ВСТАВИТЬ В Документ.РеализацияТоваровУслуг.Товары
|ЗНАЧЕНИЯ (ВЫБРАТЬ &Приемник, * ИЗ Документ.РеализацияТоваровУслуг.Товары ГДЕ Ссылка = &Источник И НомерСтроки = 1)

Там только одна строка - или, скажете, что так тоже будет работать:

|ВСТАВИТЬ В Документ.РеализацияТоваровУслуг.Товары (Ссылка,*)
|ВЫБРАТЬ &Приемник, * 
|ИЗ Документ.РеализацияТоваровУслуг.Товары 
|ГДЕ Ссылка = &Источник


Ну или хотя бы так

|ВСТАВИТЬ В Документ.РеализацияТоваровУслуг.Товары (Ссылка,Номенклатура,Цена,Количество,Сумма,СуммаНДС,СтавкаНДС)
|ВЫБРАТЬ &Приемник,Номенклатура,Цена,Количество,Сумма*(&Наценка),СуммаНДС*(&Наценка),СтавкаНДС
|ИЗ Документ.ПоступлениеТоваровУслуг.Товары 
|ГДЕ Ссылка = &Источник


Ну это по ANSI SQL, а у вас, возможно, надо так написать

|ВСТАВИТЬ В Документ.РеализацияТоваровУслуг.Товары (Ссылка,Номенклатура,Цена,Количество,Сумма,СуммаНДС,СтавкаНДС)
|ЗНАЧЕНИЯ (
|ВЫБРАТЬ &Приемник,Номенклатура,Цена,Количество,Сумма*(&Наценка),СуммаНДС*(&Наценка),СтавкаНДС
|ИЗ Документ.ПоступлениеТоваровУслуг.Товары
|ГДЕ Ссылка = &Источник
|)


Чтобы вставить все строки документа (по условию)

Может даже можно упросить

|ВСТАВИТЬ В Документ.РеализацияТоваровУслуг.Товары
|ЗНАЧЕНИЯ (
|ВЫБРАТЬ &Приемник,Номенклатура,Цена,Количество,Сумма*(&Наценка),СуммаНДС*(&Наценка),СтавкаНДС
|ИЗ Документ.ПоступлениеТоваровУслуг.Товары
|ГДЕ Ссылка = &Источник
|)


5. Конечно решается - но хочется же по-проще и покрасивее :-) раз уж делаете расширение - в 1С такие апдейты очень востребованы просто (после апдейтов регистров сведений, что из п.1)!

6. Конечно, в первую очередь интересна запись данных (но чтение тоже можно сделать для комплекта - бывают тяжёлые запросы которые эффективно выполяются параллельно). Думаю, для начала можно было бы просто дать управляющие инструкции вызывающей стороне - чтобы она сама решала как ей распараллелить. Она же может задать ключевые поля - состав которых образует параллельные ключи - наборы по разным ключам можно писать параллельно. Ну и авторежим хорошо бы - например по разным ссылкам документов,справочников или регистраторам РС можно смело писать паралельно (где это разрешено опцией, а то в файловой БД это, конечно не так),

Того глядишь Вы зададите новый тренд развития платформы 1С и такие идею появятся в будущих редакциях уже в платформе!
22. m-rv 627 29.08.18 11:39 Сейчас в теме
(21)
4. да конечно, это просто пример. можно сколько угодно строк вставлять. ваш последний запрос взлетит прям в таком виде.
Оставьте свое сообщение