0. m-rv 700 31.05.18 08:36 Сейчас в теме

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

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

Перейти к публикации

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

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

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

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

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

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

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


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

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


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

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


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

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

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


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

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

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

Вакансии

Работа от Инфостарт
Санкт-Петербург
Временный (на проект)

Руководитель отдела внедрения 1С
Новосибирск
зарплата от 60 000 руб. до 160 000 руб.
Полный день

Ведущий программист 1С
Москва
зарплата от 120 000 руб. до 150 000 руб.
Полный день


Ведущий программист 1С
Сочи
зарплата от 82 500 руб. до 99 000 руб.
Полный день