http://v8.1c.ru/o7/201401query/index.htm
Кто что думает?
В тему
v8: Запрос в 8000 строк с 70 параметрами это нормально?

почти ничего не поменялось

заманивают на 8.3?

(2) а как же еще...

(0) 8.3.5 ?

(1) А как же объектная модель?
По поводу списка выборов запроса и пакета, наверное это как раз для очень больших запросов

1С — это тоже не очень нормально, но работаем же.

(5) построитель не осиливают что-ли?

(2) там еще такая долгожданная фенька появилась:

"...вы можете просто найти все места, где используется некоторая переменная, функция или процедура. С помощью команды Найти использование:"
http://v8.1c.ru/o7/201312ref/11.png


//жалкое подобие SciColor в 1С77  :-)

Какие теперь соединения красивые, для одаренных пишут какое соединение - левое,правое али полное.)
Объектная модель ооочень удобно.
Интересно как это работает  по срезам, где передаем параметры виртуальной таблице и отдельно отбор по ресурсам потом накладываем.

а есть изменения для условий вида

Ссылка В (ВЫБРАТЬ ... ИЗ ...)

в том числе коррелируемые?

(10) Надо смотреть. Мне кажется вот это Операторы[0] - отвечает за оператор ВЫБРАТЬ как раз. Отсюда и шагать можно будет.Хотя всё это только мысли.)

(10) За это руки отрывают.

Ой хочу. Кто могет поделится?

(0)
О всего 8 лет прошло и они догадалиь, что левое соединение - это "дерево"

Но спасибо

(5)А как же объектная модель?
- и что? это не ОМ, это - просто хэлп по ранее созданному запросу.
Т.е. Вы в любом случае напишите поля из запроса, просто теперь - они будут в "подсказке". Только и всего.
(да, это ОГРОМНЫЙ шаг для 1С! конечно же! а как же!!!)
(8) там еще такая долгожданная фенька появилась
- да, сделали поиск по тексту... а я раньше через поле "Найти..."
(5)По поводу списка выборов запроса и пакета, наверное это как раз для очень больших запросов
- пакет запросов с самой 8.0 присутствует. Так что тут сделано "для больших запросов"?

(9) Точно так же как и в СКД. У жертв автозаполнения, понятно, работать не будет.

(14)
О всего 8 лет прошло и они догадалиь, что левое соединение - это "дерево"
- а правое и полное - это не дерево?

о как... а настройки в xml выгрузить/загрузить можно будет в тонком из внеш. обработки? там же безопасность...

полное это что будет? роща?

(17)
И что, зачем этот пост ?
Но в любом случае молодец , что догадался - 5

внутреннее - полено?

ну вот накой эти костыли??!!

сделали - так обеспечьте одинаковое поведение во всех режимах. Накой плодить "нюансы" на ровном месте

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

Жить становится веселее!

Но сам факт, что теперь конструктор доступен под тонким клиентом - "бомба"! И что главное - во время то как. Теперь придется все ярлыки запуска толстого клиента прибивать :)

Либо я че-то не понимаю, либо не полноценная модель, как добавлять соединения и объединения не пойму...

Если объектная модель - альтернатива формирования нужного текста запроса в виде строки, то должны быть доступны все конструкции запроса.

Хотя возможно я спешу с выводами...

(23) Как-то. Как выйдет тестовый релиз с этой фичей, так и узнаем.

(23) Это просто ПостроительЗапроса на СКД

(21) зарплата вырастит 1С-ника еще больше :)

(12) нормально там все, тестировалось неоднократно, особенно как условие для виртуальной таблицы

(8).. +100

(0) И когда я его увижу у себя на компе?

(0) Круто, че

Конструктор в УФ, конечно, был нужен.
А вот объектная модель - лучше бы ошибки платформы чинили.
Бедные юзеры - силком сажают на 8.3, а на мисте каждый день плач про её глючность.

Дата релиза когда ?

(33) 27.02

(32) 8.3 идеальна!

(34) а год?

По описанию главное что сделали -
- объектная модель запроса (полезно в основном для построения динамических запросов и создания всяких инструментов разработчика =) и универсальных механизмов)
- работа в тонком клиенте
- стало удобнее работать с большим числом запросов в пакете и выборок в объединении

По новому режиму редактирования связей пока не очень понятно, на сколько удобно будет. В моем конструкторе запроса точно сделано удобнее чем в текущем платформенном даже без перетаскивания.

>>Объектная модель схемы запроса
- то что нужно, давно пора было сделать

(36) Enter.

(37) а чем построитель запроса не устраивал?

(40) Тем, что например соединения в нем создавать программно нельзя.

(36) 2018

(41) там можно делать необязательные соединения

(15) "- да, сделали поиск по тексту... а я раньше через поле "Найти..."

Ты явно не в теме

(43) Через установку полностью всего текста - да, но это другой уровень удобства =)

(12) а в чем проблема?

(12) (46) Тоже интересно)

Круто, что в тонком клиенте работает.
Где достать то?

Как дела с ЗНАЧЕНИЕ(Перечисление...)? Если не трогать объектную модель.

(48) Внешней обработкой хотел)

Долго думал, где реально будет удобно использовать объектную модель запроса... Не придумал.

Якобы алгоритмы формирования динамических запросов должны стать менее громоздкими. Что-то мне кажется, будет с точностью до наоборот, да еще и менее прозрачно.

(48) Попутал я что-то. Думал, что речь про консоль запросов)

(53) так и консоль будет

ничего не понял, но выглядит симпатично.

По поводу списков запросов пакета и операторов непонятно, как выполняется добавление/удаление элементов этих списков. В общем надо смотреть. Пока нельзя потрогать, фантазия будет достраивать все традиционно оптимистично =)

(56) А все, увидел. Закладки "Пакет" и "Объединения" оставили.

ООП часом в 1С 8.3 не ожидается?!

(58) Ну только если не нарушит обратную совместимость

(44) ну да, я не в теме восторга от бесконечного топтания на месте и резких прыжков в сторону.

(0) Мне не нравится новшество в соединениях - "левое соединение". Я уже и не помню - что значит левое, что правое. Очень удобно в конструкторе поставить галочки у нужной таблицы, а теперь надо переучиваться.

(51) Везде, где раньше писали

Запрос.Текст = СтрЗаменить(Запрос.Текст, "ЧтоТоТам", "ЧтоТоТамПлюсЕщёЧтоТо");

И это замечательно, потому что бывали случаи, когда СтрЗаменить переставал работать, если при обновлении запрос изменился. А искать такие баги на ровном месте...
Теперь такого не будет. "Хватит это терпеть!" (c) Жириновский =))

(61) ну ты даешь, я как раз не понимаю эти галочки...

как дела с временными таблицами в динамических запросах?

(20) объясняю: соединения всегда были в виде дерева. И дерево всегда отображалось. И тогда, и теперь.
А вот визуально изображение дерева сменилось.
Так понятней? ))

(62) да ничего не изменилось по сути.
Типа, стало прилизанней, но более неявно и "закопано", что далеко не плюс.
Все динамические запросы в большинстве - это кардинальная смена парадигмы запроса, используя куски запроса, а не использование и подмена динамически условий или полей внутри запроса (внутри блоков запроса).
"Динамика" внутри блоков - всегда можно обойтись ВЫБОР или условиями.

(64) да никак, это ж не на 100 лет ушедший вперед T-SQL, где можно сделать "окно" внутри результата запроса и снова наложить условия только на него.

+100

одинесовцы молодцы!

(65) а перекрестные (cross) соединения это тоже дерево или просто хорошая трава?.. :-)

(65) а когда я соединял вторую и третью таблицу, а в их условиях использовал первую, это было что?

(62) пока  текст запроса не будет плафтоврма при изменении конфигурации проверять - ничего это не даст, рантайм-еррор так и останется

(44) не надо воспринимать каждое изменение формата или раскраски в 1С как революцию в программировании.

(72) может тебе ещё компилятор в платформу встроить?

(70) вот и спросите 20) - что было раньше, и что сейчас.
Пусть с восторгом расскажет ситуацию ))
(71) ждете ответа - это было не дерево? Или, как и выше, спутали адресата? ))

Блин, а я только пару месяцев назад реализовал эту объектную модель в виде обработки. Примерно так же все работает - парсинг запроса, модификация, получение модифицированного текста.

(74) было бы неплохо.
А еще частичное исполнение кода. Но пока всех устраивает смена зеленого на желтое в панельках...

(76) боюсь, что даже парсинг текста запроса - реализован "по месту в модуле", т.е. если сделать реальный динамический запрос, прогнать и получить его текст, то никакие "новые фишки" по модификации блоков работать не будут.

Раз уж так, выложу своё.
http://code-spec.pro/index.php/---1/55-2014-01-28-06-56-39
Пока только описалово, скачивание будет чуть позже.

(79) Парсишь чем?

(28) (46) (47)

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

http://help1c.com/faq/view/1144.html

(49) Такие конструкции надо из запросов выпиливать, да и выражения в параметрах, например
Где
таблица.дата > НачалоПериода(&ПараметрДата, Год)

(81) практика порой говорит, что быстрее с условием на подзапрос

(82) ЗНАЧЕНИЕ(...) каким боком? оно как бы SQL-сервером не обрабатывается, а сервером приложений

+(84) ЗНАЧЕНИЕ(...) это не функция, это способ передачи литерала

(81) Временные таблицы ДАЛЕКО не всегда быстрее. Хотя иногда быстрее на порядок. Иногда оптимизатор наоборот - в состоянии создать более оптимальный план, когда ему принудительно не рубят алгоритм на этапы.
(82) Честно говоря, не замечал разницы в производительности между &КонецПериода и КОНЕЦПЕРИОДА(&КонецПериода, ДЕНЬ). Хотя встречал подобные рекомендации от 1С.

(83) В практике и дело, а точнее в стабильности. То есть в определенном контексте такая конструкция вреда не нанесет, но изменится версия системы (конфигурация, платформа, СУБД, архитектура, количество пользователей и т.д. и т.п.) и возможно, что данный запрос начнет выполняться по неоптимальному плану....

(84)(85) ну вот на практике я тоже глазками не видел, но рекомендуется не использовать, так как в некоторых случаях СУБД не сможет подобрать план запроса из кэша и и начнет его заново генерировать.

так что от греха лучше не использовать.

(81) На создание временной таблицы тратится время. Так что не все так однозначно.

(86) Да, при формировании временной таблицы затрачивается время на ее формирование, индексирование. Но значительно повышается стабильность работы.

(90) Я уже сказал, что дело не только в накладных расходах.
А жертвовать текущей производительностью ради пресловутой "стабильности" при гипотетических изменениях системы - сомнительная практика. Выгоднее провести оптимизацию при возникновении такой необходимости.

(91) И ты прав . Все зависит от контекста.

Но при разработке можно уже сразу закладывать "нормальные" структуры запросов, метаданных и т.д. Что бы потом с ЦУПом не ловить очевидное.

Так же естественно на запросах ворочающие небольшие таблицы можно и не придерживаться рекомендациям, так как накладные расходы могут с легкостью перевесить мнимую пользу )

(10) У них в этом месте и сам внутренний движок (aka SDBL) не всегда корректно работает. Так что пусть уж пока хотя бы просто без ошибок переваривает "как программист написал".

(92) На все случаи нормально не заложишь. Проблема в том, что сплошь и рядом 1С юзается в mixed режиме. OLTP + DW. Поэтому приходится извращаться и нашим и вашим. С упором на OLTP, ессно. И естественно, я говорю больше про узкие места производительности. Если объем данных ларечный - там вообще можно не заморачиваться.

стабильность - это везде стабильно медленно + невозможность что-то с этим сделать?

(95) ну как бы во временную таблицу кидать пол конфы не стоит. Так что при грамотном проектировании есть шанс получить "стабильно быстро" ))

(80) Не поверишь, кодом 1С :)
Не стал прикручивать regexp-ы, дабы не таскать с обработкой

(97) Очень ждем релиза, чтобы оценить скорость и всеядность.

(98) http://code-spec.pro/downloads/queryconstructor/QueryConstructor.epf

(100)

ну и в каком релизе платформы все это счастье будет?

8.5.28

(101) 8.4.1

в 9.0 будет счастье для всех 1С-программистов.
Если таковые еще будут.

Чем то похоже на построитель запроса

(105) это он и есть. Теперь "типо Визуальный".