С тем, что объект Запрос в 1С выполняет свои функции, спорить сложно. Но одинаково ли хорошо он подходит для всех случаев? Достаточно ли он лаконичен в "простых" случаях? Достаточно ли нагляден в "сложных" случаях? При попытке подойти к объекту Запрос с позиции методологии разработки возникают следующие вопросы:
- Сам язык запросов и его рекомендуемый стиль слишком громоздкий для "простых случаев". Если наплевать на рекомендуемое оформление, то запрос можно упростить до чего-то вроде "Запрос = Новый Запрос("Выбрать Ссылка Из Справочник.Номенклатура Где ВидНоменклатуры = &МойВид")", что вместе с добавлением параметра и получением результата уложится в три строки, но, на секундочку, в рекомендуемом оформлении — это 10 (десять, Карл!) строк кода.
- Нет запросов на изменение данных. Что мешало сделать простое и удобное платформенное средство непонятно: поверх платформы запросы на изменение сделать можно, значит и в слое платформы тоже было можно.
- Обвязка языка (установка параметров, работа с результатом) хоть и хорошо вписываются в стиль процедурного языка 1С, но также заставляют писать много лишних букв. Для "Запрос.УстановитьПараметр(" уже можно отдельную кнопку на клавиатуре делать
- Текст запроса имеет совершенно отвратительный вид: нет подсветки синтаксиса, необходимость в избыточном оформлении (символ | в каждой строке) делают его сложным для восприятия. Да, подсветку синтаксиса можно получить в конструкторе, но это дополнительно усложняет чтение кода, а на очистку комментариев в этом случае не матерился только ленивый.
- В "сложных" случаях длинный запрос затрудняет чтение процедурного модуля (привет ЗУПу). Частично это решают выносом текста запроса в отдельную процедуру. Так делать начали в типовых, что можно считать официальным признанием наличия проблемы.
Таким образом, можно говорить о том, что реализация запросов в 1С в целом оставляет желать лучшего, а в простых случаях, когда смысл можно было уместить в одну строку, вообще превращает код в длинное и не очень содержательное спагетти. У меня черт возьми, ощущение такое, как будто взяли 20% функционала SQL, прикинули как с помощью этого написать средненький по сложности запрос и на этом успокоились.
При этом "простые" случаи являются наиболее востребованными. Например, в типовой УТ слово ВЫБРАТЬ встречается 22 тысячи раз, а слово СОЕДИНЕНИЕ 11 тысяч раз. Если еще учесть 5 тысяч слов ПОМЕСТИТЬ и тот факт, что соединений в одном запросе бывает несколько — можно говорить, что примерно половина всех запросов являются запросами к одной таблице, т.е. теми самыми "простыми случаями". Это все конечно очень прикидочно.
Т.е. половина запросов написана с использованием инструмента, не лучшим образом подходящего для их написания. Казалось бы, в платформе есть инструмены для получения данных из базы в обход объекта Запрос, такие как НайтиПоРеквизиту, но их использование — это издевательство! Упомянутая НайтиПоРеквизиту ищет только по точному совпадению и только по одному реквизиту и то не по каждому. В типовой УТ, на весь миллион строк кода этот вызов встречается 41 раз, что можно приравнять к признанию бесполезности этого метода. Чтение набора записей регистра сведений по отбору, наверно, самый "юзабельный" инструмент получения данных из базы в обход запросов, но и в нем приходится повторять по пять раз Набор.Отбор….Установить, что не лучшим образом сказывается на читаемости и лаконичности.
Ну правда, что мешало хотябы в метод НайтиПоРеквизитам и принимать на вход структуру? Только не надо про поиск в обход индексов: если будет надо — все равно напишут запрос и будут искать в обход индексов. Займет это вместо одной строки 15, но напишут.
Чтобы окончательно проникнуться идеей ограниченности языка запросов для простых случаев — давайте попробуем глянуть на процедуру, получающую организацию по умолчанию (это не я придумал, это код типовой УТ):
Организация = Справочники.Организации.ПустаяСсылка();
Запрос = Новый Запрос();
Запрос.Текст = "
|ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 2
| Организации.Ссылка КАК Организация
|ИЗ
| Справочник.Организации КАК Организации
|ГДЕ
| НЕ Организации.ПометкаУдаления
| И НЕ Организации.Предопределенный";
Запрос.УстановитьПараметр("ИНН", МойИНН);
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() И Выборка.Количество() = 1 Тогда
Организация = Вборка.Организация();
КонецЕсли;
Возврат Организация;
Делов тут на 3 копейки, а кода 16 строк. Препишем эту функцию на русском языке:
Найти первые две не помеченных на удаление, не предопределенных организации. Если нашлась одна — вернуть ее ссылку, иначе вернуть пустую ссылку.
В этом определении нет упущенной логики, непонятных обобщений и прочих хитростей. Тот факт, что на языке простой логики функция получается в трое короче (263 символа против 900) явно свидетельствует, что выбранный для нее инструмент мягко говоря не совсем подходит. А еще можете взглянуть на мрак в Справочники.Организации.ПолучитьРеквизитыОрганизации… Так совсем не годится.
Вообще, чем меньше в том что вы пишете бизнес-логики и больше каких-то языковых условностей, без которых "не обойтись" — тем менее "плотным", лаконичным будет код, тем больше он будет похож на спагетти, тем хуже он будет читаться и дебажиться.
В 1С явно нужен инструмент, позволяющий получить доступ к данным более лаконичным образом чем язык запросов. Естественно, при этом придется поступиться широкоуниверсальностью, но не настолько чтобы получить что-то бесполезное типа НайтиПоРеквизиту. Хорошо бы получить что-то типа такого:
Организация = Справочники.Организации.НайтиПо("НЕ ПометкаУдаления").ИПо("НЕ Предопределенный").ПолучитьСсылку(Истина);
или типа такого:
Организация = Найти.В("Справочник.Организации").По_("НЕ ПометкаУдаления").ИПо("НЕ Предопределенный").ПолучитьСсылку(Истина);
Как вы пониматете, ничего невозможного в этом нет, а разница между первым и вторым только в наличии функции НайтиПо в модуле менеджера, которая делает вызов Найти.В…
Итак, чтобы не писать каждый раз портянку одинаковых букв, план такой:
1. Делаем общий модуль Найти
2. Пишем в нем обёртку над языком запросов, что-то весьма функциональное, но с простым лаконичным АПИ.
3. Встраиваем вызов процедуры в каждый (или в нужные или только в те, что сняты с поддержки) модуль менеджера.
4. …
5. PROFIT!
Писать такое не долго, весь мой модуль занимает 250 строк. Делать ли вызов процедур "в одну строку" или нет — вопрос дискуссионный, как делать написано тут.
Некоторые сухие подробности реализации:
- Функция НайтиПо(Параметры…) — функция модуля менеджера, объединяющая указание таблицы и первый фильтр
- Функция задания имени таблицы: В(Имя); Имя — указывается имя таблицы. При встраивании в модуль менеджера пишется один раз или, если встраивание невозможно или нежелательно — каждый раз.
- Функции фильтрации: По_() ИПо() ИНе() ИлиПо() ИлиНе() — функции добавления параметров с соответствующей булевой операцией. В параметрах указывается: имя фильтруемого поля (или само выражение его фильтрации, как в примере "дата между") и, при необходимости, параметры фильтрации. Здесь необходимо пояснить, что для достижения максимальной гибкости и естественной простоты функции пришлось сделать три случая ее функционирования:
- без параметров, для обработки случаев типа И("НЕ ПометкаУдаления")
- с одним параметром, для простого добавления простого равенства, например: И("ВидНоменклатуры", МойВид)
- со сложной обработкой параметров, например: И("Дата МЕЖДУ &Дата1 и &Дата2", ДатаНачала, ДатаКонца). В таком варианте можно задать до трех параметров, а их использование в явном виде указывается. Параметры подставляются по порядку, т.е. в данном случае ДатаНачала будет сопоставлена &Дата1, а ДатаКонца — &Дата2".
- Если использована функция отрицания: ИНе() или ИлиНе()- вся добавленная фраза будет завернута в "НЕ (…)"
- Функции получения результата:
- ПолучитьТаблицу() — эквивалентно "ВЫБРАТЬ * " в запросе и "Запрос.Выполнить().Выгрузить()" в обработке результата
- ПолучитьСсылки() — эквивалентно "ВЫБРАТЬ ССЫЛКА" в запросе и "Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Ссылка")" в обработке результата
- ПолучитьСсылку(ТолькоУникальную) — возвращает первую попавшуюся ссылку, соответствующую указанным критериям. Если не найдется — будет возвращено Неопределено. Параметр ТолькоУникальную не обязательный, по умолчанию Ложь, если установлен в Истина — ссылка будет возвращена только если нашлась одна ссылка по указанным критериям, если найдется две — будет возвращено неопределено.
- ПолучитьСсылкуИлиЗначение(ЗначениеПоУмолчанию) — тоже что предыдущее, но если не найдется — будет возвращено ЗначениеПоУмолчанию
- ПолучитьСсылкуИлиИсключение(ТекстИсключения) — тоже что предыдущее, но если не найдется будет вызвано исключение
- ПолучитьПараметры(СписокПараметров) — эквивалентно "ВЫБРАТЬ *" в запросе и помещению первой строки результата запроса в структуру, где ключ соответствует имени колонки, а значение — значению этой колонки в первой строке (если строк не будет — Неопределено) СписокПараметров необязательный, если не задан — в структуре будут заполнены все реквизиты, если задан — в структуре будут присутствовать только указанные реквизиты.
- Пара примеров:
- Документ.ПоступлениеТоваровУслуг.НайтиПо("Номер", Номер).И("Дата Между &Дата1 И &Дата2", Дата1, Дата2).ИНе("ПометкаУдаления").ПолучитьТаблицу();
- Справочник.Номенклатура.НайтиПо("ВидНоменклатуры В (&Виды)", МассивВидов).ИЛИ("СтавкаНДС", Перечисления.СтавкиНДС.НДС0).ПолучитьСсылки();
Платформа 8.3.9.2233, код открыт, даунгрейд возможен при реализации функций типа СтрНачинаетсяС.
Удачи!
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Речь идёт только об однопакетных запросах без соединений?
1. не громоздкий, все нормально! Упрощение не всегда означает «удобство чтение».
2. да это наоборот плюс что нет запросов которые модифицируют данные! Вы хоть представляете сколько опасных ситуаций могло бы возникнуть из за кривости рук программистов?
4. согласен насчет подсветки — было бы хорошо ее добавить
5. какие проблемы? вы о чем? вы бы писали 5-километровый код строками вместо пары запросов?
Ваши предолжения «найтиПо» и «ИПо» — это просто жесть!
Я рад что вы не работаете в 1С и не развиваете продукты, иначе это стало бы концом фирмы!
Есть конструктор с обработкой результата, все параметры и даже циклы (которые потом почти всегда приходится удалять) пишет за программиста, главное только запрос наклацать.
js’ом надышались? 😀
я сделал шаблон кода
по строке «Запрос = »
шаблон напишет всё что написано в верхнем запросе 🙂
так ещё легче
Запрос = Новый Запрос;
ТекстЗапроса = »
|ВЫБРАТЬ
|
|ИЗ
|
|ГДЕ 1=1
|
|»;
Запрос.Текст = ТекстЗапроса;
Запрос.УстановитьПараметр(«», );
Результат = Запрос.Выполнить();
Выборка = Результат.Выбрать();
Если Выборка.Следующий() Тогда
КонецЕсли;
Я вообще люблю почитать запросы в 1С. Вечером лежа в кроватке перед сном. Успокаивает нервную систему, нормализует давление, хорошо влияет на сон.
(2)
2. вот мне в статье про запросы на изменения тоже писали что типа все пропало, теперь все будет плохо, но никто не может сказать почему. чем конкретно опасны запросы на изменения? чем фраза «УДАЛИТЬ ИЗ РегистрСведений.ЦеныНоменклатуры» опаснее фразы «РегистрыСведений.ЦеныНоменклатуры.СоздатьНаборЗаписей().Записать()»
5. имеется ввиду, когда внутри процедуры на 200 строк еще запрос строк на 100
(4) джавой
Конструктор запросов это лучшее что у нас есть!
(2) НЕ согласен по некоторым моментам.
2. Кривость это плохо, но зачем ограничивать тех, у кого все растет откуда нужно? Или их настолько мало, что не имеет смысла заморачиватся? 🙂
4. Для 1С это просто текст, учитываю то, что нет качественной подсветки основного кода, то я думаю этого не будет сделано от слова никогда
5. Есть функциональный подход в том же LINQ. И что в этом многокилометровом коде такого плохого? Можно прикрутить и групджоины и т.д. и все это вполне замечательно читается и видно последовательность действий. Поэтому я кстати и не люблю декларативный синтаксис. Простой пример, отбираем записи по условию, сортируем туда обратно и выбираем например 10 записей пропуская первую. Помоему все лаконично и удобочитаемо:
var row = db.table
.Where(x=> x.field == foo)
.OrderBy(p=>p.date)
.OrderByDescending(p=>p.level)
.Skip(1)
.Take(10).
.ToArray(); /// например
(2)
INSERT/DELETE- AddRange/RemoveRange, апдейта прямого нет конечно, т.к. линкю работает с объектной моделью и очень часто проще удалить и вставить новые записи.
Есть декларативный язык, есть флюент апи с лямбда синтаксисом. Т.е. вы хотите сказать, что годы развития данных технологий так — за хлебушком ходили? По поводу «жести» я бы поостерегся, не нужно судить все с колокольни 1С, т.к. она по удобству разработки, языку, среде выполнения находится на задворках вселенной.
(10)
4. ну когда я думал на эту тему — я думал, что в каждом серверном модуле можно сделать пару вкладок: для процедурного языка и для языка запросов с соответствующей подсветкой в каждой. но это конечно врядли будет реализовано
5. я начал думать от spring data. там пилятся методы типа findByEmployeeAndDateBetween(Employee emp, Date date1, Date date2) без реализации и движок парсит имя метода и понимает что делать надо
(5) это только подтверждает основную мысль: текущая реализация изобилует обвесом, который ни на что не влияет
(9) «— Вы же знаете греческие трагедии? Еврипид, Эсхил, Софокл… Одним словом, Греция. Старина — это лучшее, что у нас есть.» © Мураками
Автору, конечно, спасибо за статью-всё-таки на это было потрачен драгоценный ресурс — время. Но! Все же не соглашусь с идеями статьи. Хочу сказать, что идеальных инструментов не бывает, это во-первых, во-вторых, и отвёрткой можно забивать гвозди, если надо будет. Но инструмент может приносить в этот мир достаточно сложные и лаконичные вещи в руках умелого мастера…)
Интересно
(7)
вы привели только частный случай опасного удаления записей.
Вот пример «УДАЛИТЬ * ИЗ Документы.РеализацииТоваровУслуг» — удалиться все документы без проверки ссылочной целостности, и концов не найдешь!
А если объект сам удаляешь, то хоть ЖР остается кто удалил
Тезисно
1. Про избыточность синтаксиса в простых случаях. Нормальный синтаксис и со временем читается очень даже нормально.
2. Про INSERT — запросы отправляются на сервер БД — как работать с обработчиками ПриЗаписи, ПередЗаписью и подписками на события?
3. Про подсветку кода, комментарии и автокомплит — они есть в EDT. Попробуйте, новый конструктор вполне себе торт.
Собственно проблема на с языком запросов, а с культурой программирования. Обычная практика — работа с БД и бизнес логика в одной процедуре, хотя, по-хорошему, надо разделять.
Такой синтаксис трудно воспринимается. Подумайте о других или о себе через пару месяцев после написания такого…
Несомненный плюс запросов в том, что их достаточно легко прочитать. А читаемость кода важнее экономии места в модуле.
Лично мне не хватает функциональности языка ака вложенные циклы (селекты в полях выборки) + подзапросы в соединениях. Всего эти две простые вещи сделали бы меня счастливым…
Остальное всё пусть будет, как жираф решил.
(16)
я не понимаю разницы между Объект.Удалить() и «УДАЛИТЬ ИЗ Документы.РеализацииТоваровУслуг». запись в ЖР можно делать и в обоих случаях. в «не тех руках» оба инструмента приведут к одному результату
Хайп детектед 😉 Не согласен с бОльшей частью претензий. Наверное, единственное, с чем согласен — нужна возможность писать комментарии в запросах.
(18) Создатели fluent api нервно курят в сторонке от таких заявлений.
ИМХО Как раз то читаемость кода во флюенте выше, чем в декларативном виде. Просто если нет опыта в нем, не нужно судить автора статьи.
(17)
Тут есть люди которым флюент кажется жестью, хотя чтобы привыкнуть к нему требуется пара дней
2. Entity framework прекрасно работает с моделями представления записей таблиц, там есть так нужные вам и при записи и перед и вдоль и отличия старой записи от новой без всяких сохранений в доп свойствах. И все это отлично работает и с декларативными запросами и со флюентом/лямбда.
(17)
Есть такой пример разделения — фрейворк MVC, там и есть разделение самих моделей данных, работа с ними по запросам и собственно сами формы (view).
(6) Вы работаете с ЗУПом 3 перед сном? :)))
(17)
2. ну вот тут это как-то работает:
3. в edt подсветки синтаксиса запроса небыло.. по крайней мере в тексте процедурного модуля. допилили?
(25)
2. Там просто синтаксический сахар, т.е. если в запросе микс из Выбрать и Изменить — будет несколько запросов, что будет работать некорректно.
3. Проверл — вполне работает (приложил скриншот)
(21) так комментарии пишутся, только конструктор их выкашивает сразу же
(27) о чём и речь 🙁
В общем автор хочет аналог ORM из RoR в 1С. Здравая мысль, но никогда реализована не будет.
(20) как вы привяжете к выполнению SQL запроса регистрацию удалений? Если там удаление происходит 111 таблице?
1C же все переводит в SQL запрос и потом его просто бахает на выполнение
по поводу удаления могу сформулировать так — чем проще удалить объект без контроля, тем больше рисков.
Какой нибудь криворукий программист напишет вам кривое условие в конструкции «УДАЛИТЬ * ИЗ … ГДЕ _некоторое условие_» — и все, потом не отладить, ни концов найти.
Все вышесказанное относиться и к «ИЗМЕНИТЬ»
(30) в sql именно на этот случай существует журнал транзакций с полной моделью восстановления.
Удалить этот своего рода блокчейн можно изменив модель восстановления и обрезав журнал транзакций.
(31)
я как 1С программист мало взаимодействую с SQL, поэтому возникает вопрос.
Как оперативно посмотреть кто снес 100 документов? в ЖР это можно увидеть досточно быстро.
В варианте серверной SQL базы — обращаться к админам, что бы развернули копию базы до удаления записей? Это разве выход? Если база гигантская?
Опять же в вашем посте нет ответа — как определить пользователя, который снес документы.
и еще вопрос — как быть с файловой базой?
(30) вы отождествляете выполнение запроса в 1С и выполнение запроса в SQL. не факт, что стоит делать один-в-один. посмотрите как сделано тут:
без контроля никто не предлагает удалить
(26)
2. это следствие ограничений платформы. внутри платформы можно было бы сделать чтобы корректно отработал микс
3. это текст процедурного модуля или этот редактор надо отдельно открыть?
(32) в sql есть функции просмотра транзакт лога
Проблема в том, что 1с сервер это один пользователь и даже с полными правами.
По поводу файловой базы вопросы в техподдержку 1с.
(8) Я в руби наковырялся вот с такими выражениями «в одну строку». Это прикольно для примитивных операций и только. Ну и на «прикольно» всё удобство и заканчивается. Ускорения в разработке не заметил вообще. Особенно учитывая перемешку полноценных запросов и таких однострочников, а потом необходимость переделывания однострочника в полноценный запрос.
(34)
2. это следствие ограничений платформы. внутри платформы можно было бы сделать чтобы корректно отработал микс
3. это текст процедурного модуля или этот редактор надо отдельно открыть?
2. Это в любом случае будет неоптимально
3. В редакторе текста запроса EDT
(37)
2. все будет ок
3. речь шла о виде запроса в тексте процедурного модуля
И как часто приходится писать такие простые запросы? Хорошо если 1 из 50 запросов будет без объединений,
(40) вы хоть поняли что сказали?
(40)
можете аргументировать почему фирма 1С движется к своему концу?
Без обид, готов с вами поспорить и ответить на конструктивную критику
(40)
Возможно, для самой фирмы это слишком категорично, но вот для V8 это весьма очевидно.
(40) (42)
вы делаете весьма огрубляющее обобщение. есть векторы направленные как в одну так и в другую стороны:
— если говорить о скорости выпуска «больших» продуктов — тренда на спад не прослеживается:: 2000 — 8.0; 2010 — 8.2; 2016 — EDT; 2018 — месенджер и 8.4. Разработка конфигураций, по моему оценочному мнению, по сравнению с 2010 годом находится на небывалой высоте как по скорости так и по сложности
— выручка также растет (в 18-м году слегка упала, но пока нельзя говорить что это тренд) и, судя по всему, фирма глубоко прибыльна.
— в технологическом смысле фирма проводит двоякую политику: с одной стороны закрытость «внутреннего мира» можно назвать неким изоляционизмом, а изоляционизм всегда приводит к одному результату (и не подумайте что я намекаю на какие-то параллели))) с другой стороны поддержка rest сервисов в обе стороны делает возможными любые интеграции
— также, можно сказать, что очень опасным трендом является пренебрежение к программистам 1С со стороны программистов «взрослых» языков, что приводит к «непристижности» профессии и оттоке тех, кто может «оттечь», что будет приводить к снижению качества прикладных решений.
— и еще один крайне тревожный тренд заключается в том, что все больше и больше ресурсов как фирмы 1С так и всей отрасли в целом уходит (и по всей видимости тренд будет только нарастать) на удовлетворение хотелок гос.органов, а не бизнеса, что само по себе непроизводительные затраты, не приносящие ни прибыли ни технологического развития.
(42) Говоря коротко, оппортунизм вместо профессионализма.
Что мешает Автору, описать самому все эти функции, какие нужны и тягать их в нужные модули из шаблонов.
Я думаю, что у каждого программиста должна быть своя библиотека подобных «универсальных» функций, ибо зачем и без того монструозный движок перегружать ещё больше.
(40)
«1С ещё пару лет и фсёёё, надо валить» слышу эту мантру с 2008 года….
(47) И где вы только подслушиваете.
(47) может и надо, но на топовые должности навыки атрофированы, а для нормальных не топовых должностей даже самый заштатный 1с ник слишком крут.
Не возьмут. Грызите гранит…
(45) «в нужные модули из шаблонов» — это имеете ввиду вставлять как предлагали в 5 комменте? это частично облегчает ситуацию в момент написания кода, но никак не облегчает в момент чтения и не отменяет необходимости в лаконичных языковых конструкциях.
про монструозный движок вы ошибаетесь: если взглянуть на совокупность технологий (запросы, скд, объекты, формы и пр.) то они действительно представляют весьма монструозное впечатление. но каждая технология по отдельности весьма скудно реализует свой функционал, что я показываю на примере языка запросов
(46) напишите, пожалуйста, подробнее.
Ато вдруг уже надо о переквалификации задуматься.
(49) вот тут, например —
Цитата из статьи.
Вот уже несколько лет с коллегами и друзьями обсуждаю одно профессиональное опасение и противоположный ему вопрос:
Опасение: Хоть бы новые «не нарожались» и я ещё лет десять зарабатывал себе спокойно.
Вопрос: Почему от года к году работы всё больше, а конкурентов всё меньше?
Опасение к настоящему моменту устарело и силу свою утратило, вопрос остался.
2012 год, однако.
По п2 вполне понятно почему, интересно как автор с помощью DELETE собрался удалять документ или справочник с несколькими табличными частями? Это ведь то же таблицы, контроль целостности разработчик будет делать? Ну и про события модуля менеджера можно забыть.. я предпочту иметь модуль менеджера, чем иметь DELETE, который пригодился разве что для непереодических регистров сведений.. для периодических уже таблицу срезов чистить надо и простой DELETE там не прокатит.. а что будем делать с проверкой ролевой модели доступа? не нужно это все от слова совсем, все таки в 1с мы работаем с объектами, а не с табличной моделью.
По статье согласен с тем что отборы в 1с устроены не гибко, более менее гибко — в СКД, но к сожалению компановщик настроек нельзя запихнуть как параметр отбора в функцию .Найти( . Ну и комментарии в запросах очень нужны, приходится извращаться для того что бы прокомментировать какие то куски в запросах
(54) хоспади! ну вот же все работает
«Работы все больше, а конкурентов все меньше»
Это хороший признак или плохой? Как по вашему?
(51) Имелось ввиду, что оформить это всё как функцию/процедуру и хранить это дело в шаблонах. Типа:
(56) хороший вопрос. Прошлось задуматься.
Т.к. я работаю с 1С прямо сейчас, то для меня на ближайшие 1-3 года это хорошо.
Меньше конкуренции, больше спроса на мои навыки.
Но на перспективу в 10-15 лет признак, конечно, негативный.
Если дефицит специалистов превысит некий пороговый уровень (по времени поиска специалиста, по стоимости работы специалиста и т.п.), то бизнес может для решения проблем, которые сейчас решаются с помощью 1С, использовать что-то еще.
И тогда придется переучиваться на что-то другое. А это всегда затраты времени, сил, денег.
Но сама фирма 1С, судя по всему, видит проблему. Не раз видел новости на эту тему. Например, что где-то в школах начинают продвижение профессии программист 1С.
Конечно. Фанатеем от них
(55) там циклом обычное создание элементов через модуль менеджера, мне кажется вы не понимаете чем отличается вставка строки таблицы напрямую в субд от вставки через «прокладку» 1с сервер например. То что в статье никакого отношения к инсерту не имеет, это обычная консоль запросов с обработкой результата + допилен синтаксис запросов. Вашу энергию, да в мирное русло бы…
ПС: в чем смысл то? уменьшить количество строк кода? ну видел я код вида
Человек экономил буквы) вы то же этим занимаетесь?
(58) да, пропаганда этого дела ведется — это факт, но тут есть еще один аспект: если у вас низкая конкуренция — у вас нет стимулов двигаться вперед, изобретать лучше и быстрее.
(57) да, это как раз то что я имел ввиду.
такая функция может иметь большую или меньшую вариантивность, и вы привели вариант с меньшей вариативностью (и совсем не факт плохо это или хорошо), но моя общая мысть заключалась именно в необходимости таких оберток. мой вариант обертки — уже частность.
(10)
Такой синтаксис:
«var row = db.table
.Where(x=> x.field == foo)
.OrderBy(p=>p.date)
.OrderByDescending(p=>p.level)
.Skip(1)
.Take(10).
.ToArray(); /// например »
Для меня читается намного сложнее, чем запрос, в котором все разложено по полочкам, вот условие, вот сортировка, то что много строк получается — это на любителя, когда читаю код некоторых «экономов» просто офигеваю, с какой целью несколько операторов присваивания умещают в одну строку или запрос вытягиваю в одну длинную строку и тому подобное.
Возможно это все последователи секты «ненавидящих пробелы» и их подмножества «любителей длинных строк».
(61) вы задаетесь очень комплексным вопросом. в целом, развитие всех языков программирования идет к уменьшению затрат на разработку и поддержку функционала. если предельно это упрощать, то да, нужно чтобы было меньше букв и их было легче читать. в этом смысле ваш пример соответствует критерию уменьшения букв, но не способствует читаемости.
Запрос типа ВСТАВИТЬ это конечно просто обертка над объектной моделью, я никогда не пытался утверждать обратного
(64) Чисто ради интереса. Вы ссылаетесь на (10), (10) ссылается на (2). А оповещения приходят мне).
Непонятные привязки..
после лаконичного синтаксиса python 1С-ка боль))
Мне в запросах больше не хватает возможности выбирать уникальные идентификаторы элементов…
(21) Комментарии, подсветка, свертка, автокомплит. В принципе, всё.
В БСП такое уже есть:
ОбщегоНазначенияКлиентСервер.ЗначенияРеквизитовОбъетов()
Кстати, в запросе из статьи нет условия
мне нравятся запросы хоть на 1С, хоть на SQL. А ЭТО не нравится.
Каждый инструмент хорош для своих целей.
И классические декларативные запросы
И функциональные текучие
Основной плюс последних я вижу в динамическом формировании текстов и параметров, а также сохранение единой стилистики код
(67) ммм, python, код которым хочется любоваться.
МММ, а в чем проблема большого числа строк, один фиг руками все это пишут и правят только извращенцы.
Конструктор с обработкой результата и 2 клика, делов то.
Такая запись,ну ввиде такой Организация = Найти.В(«Справочник.Организации»).По_(«НЕ ПометкаУдаления»).ИПо(«НЕ Предопределенный»).ПолучитьСсылку(Истина); сосиски пом оему наборот читается хуже.
А не достаточно ли будет раскрасить код запроса в тексте модуля так же как в конструкторе? Может фон текста чуть офф- сделать? Я немного писать пыталась, но имхо проблема а том что кода мало в модуле и текст запроса в спойлер как то сворачивается отдельно а не всей процедурой( я текст запроса из за этого в отдельную функцию всегда стараюсь вынести).
Хотя для поиска по реквизитам одного элемента использовать запрос тоже можно, вместо выборки по условиям отбора, но я не совсем понимаю разницу между запросом и выборкой, в профайлере они что, блокируются по разному?
Когда приходится дорабатывать или исправлять очень большой запрос, в котором много временных таблиц, и который собирается из частей программным путем, то хочется прибить того, кто это придумал…
Но с другой стороны, объектная логика будет ооочень медленной… что не приемлемо…
Так что компромисы неизбежны… и чаще всего побеждает производительность в ущерб удобочитаемости…
Но в одном автор прав… в простых случаях объектная логика была бы вполне приемлема, т.к. внутри все равно выполнялся бы аналогичный запрос… так зачем его самому писать?
(5)Зачем отдельный шаблон Чем встроенный в конфигуратор конструктор запроса с обходом плох?
(76)Здесь тоже можно собирать по частям (но только не тупым текстом, а путём вызовов операторов — т.е. функций) — в чем проблема?
(77)вот так выглядит подсветка синтаксиса на C#
(79) извините, не понял что вы имеете ввиду… не могу ответить…
(81)Посмотрите тут (77)
(82) комментария (77) похоже не существует….
(77) Не хотел тут флудить на эту тему, повторяться тоже не хотел — но если интересно см ссылку на комментарий по номеру слева от этого теткста (ещё можно найти по строке «77.» или по строке даты «06.11.19 13:22»)
Это в ответ на (83)
(83)