Давненько не заводили ветку, кто что хочет от 1С в новых релизах.
Кто чего желает? :))

(198) Сервер должен оповестить клиента уже тогда, когда клиент "ушел с него".
В модели веб-сервера сделать это не возможно.
В модели tcp-сервера сделать это возможно:

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

Остановимся на том, что в модели веб-сервера сделать это невозможно.

1Сники в своем уютном мирке такие 1Сники.

(193) Читай http://dolboeb.livejournal.com/3045738.html
Где-то писали, что, поскольку мобильные устройства и тактильные экраны все больше входят в нашу жизнь, то нельзя закладываться на действия при наведении мыши.

(196) А, кстати, почему?
Желание-то законное, кстати. Взял, запустил проведение документов и дальше шаришься по базе, что такого? СКД же уже так работает.

(202) Создается отдельный, самостоятельный сеанс, как будто запускается отдельный пользователь, но без интерфейса.

(203) Хм. А СКД нет, я так понимаю?

(199) в модели веб сервера есть вебсокеты, и как-то сотни и тысячи клиентов работают. есть лонг полллинг.

(199) > Сервер должен оповестить клиента уже тогда, когда клиент "ушел с него".

а почему бы и нет? не получилось - сбой оповещения и все дела. сессию с клиентом идентифицировать возможно.

+(201) Упс, не та ссылка :))
https://wonderland.v8.1c.ru/

(207) Быстрее бы 8.3.10 в продакшн ушла.

(205) Что такое лонг-поллинг?

(209) Все, почитал.
Надстройка над http с борделем и девицами.

(210) Так что про (204)-то?
Для СКД сделали, значит, а для остального тоже хотелось бы.

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

(212) Я бы даже сказал, не с проведением, а с произвольным кодом.

(213) Магия. Тьма покрытая мраком. Постарайтесь перечитать мои мысли выше еще раз.

И насчет лонг - поллинг.

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

Хочу модуль ссылки
Хочу типовую БП+ЗУП в одном флаконе

Хочу больше котиков в 1С при выполнении длительных операций!!!! И пусть "толстый" и "тонкий" клиент как-нибудь по другому назовут, а то у меня одна клиентка аж обиделась, что она "толстый клиент".....

(216) например, новый и старый? :)

Стабильной платформы.
Замучили зависающие сеансы и утечки памяти.
Хотя не исключаю собственной кривизны рук)

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

(219) ты прсотокод пишешь х..во, поэтому у тебя по 90гиг отжирается

(21) > в форме документа было видно, проведен ли документ

В типовых это есть, только не как раньше - строкой в заголовке, а картинкой среди полей шапки документа.

(28) > Хочу возможность анализировать результат запроса в вирт. табицах.

Это сделали, см. СП -> Запрос.ВыполнитьПакетСПромежуточнымиДанными

Ветке не хватает рейтинга комментов, очень многое хочется яростно проплюсовать.

(222) Такие вещи есть на инфостарте. Там есть "профильные" темы. Что-то вроде вопросов Б. Нуралиеву.

От себя добавлю:
Хочу книжку по типовым доработкам.
В одной из веток уже писал. Хочу, чтобы там было написано: Чтобы добавить в новый документ систему "СвойстваИКатегории" нужно в форме добавить элемент: ХХХ. Потом в модуле формы добавить код: УУУ. И в модуле объекта в "ПередЗаписью" добавить код: ЙЙЙ. И в ПослеЗаписи: "Вам".

(214) "требующий отдельное соединение " - зачем?
Как я это вижу:
Сервер отработал задачу, сказал об этом соединению пользователя и оно выполняет процедуру, заданную при вызове. Конечно - в тот момент, когда другой код не выполняется.
Часто такое нужно в форме: открываем контрагента и показываем некоторые расчетные параметры - пускай они считаются где-то в фоне.

(224) А вообще, в чем проблема держать постоянное соединение? Во всяких аськах это сто лет работает и проблем не создает.

чтоб финотдел 1с образумился

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

И возможность для каждой формы задать свой цвет фона тоже в УФ должна быть. Цвет фона окошка уведомления пользователя - особенно актуально.

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

по мотивам сегодняшней партнерки:  

я хочу чтобы 1С наконец то закрыла дыры для патчей/ломалок/левых обновлений....
а БГ не хочет этого...

печалька :(

Тоже хочу, чтобы в УФ объектов можно было убрать заголовки.

Хочу также, чтобы вернули Ctrl+Y в конфигураторе (зачем убрали, кому это мешало?).

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

Ещё хочу, чтобы журнал регистрации хранился в таблице БД, а не как сейчас.

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

Хочу также, чтобы из таблиц системных и общих настроек удалялись настройки пользователей, удалённых из списка пользователей базы, а не как сейчас, когда там навечно зависают бесполезные настройки, если специально ничего не предпринять.
И - самое главное - чтобы по этим таблицам строились АДЕКВАТНЫЕ ИНДЕКСЫ, а не как сейчас, когда при каких-то несчастных 50 тысяч строк настроек индекс переваливает через 4 гигабайта, и при загрузке такой БД в файловую базу происходит жесточайший облом.

(229) Че там было?

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

(232) ЖР уже может храниться в БД.

Там сейчас - адекватные индексы, все хорошо.

А, БП 2 продлили. А ЗУП вроде нет.

Ещё хотелось бы, чтобы в автоматически генерируемых заголовках HTML не фигурировала версия обозревателя, а то запустишь сравнение конфигураций там, где версия IE не такая, как у разработчиков, и начинается - якобы изменения там, где их не было.

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

(235) "Там" - это в какой версии?

http://v8.1c.ru/o7/201310log/index.htm

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

И уж точно хочу, чтобы длительные операции (долгое проведение, загрузка базы из файла, сравнение/объединение конфигураций) не вызывали подвисание окон других процессов - почему-то только 1С иногда вызывает подвисание других программ - из-за этого приходится отдельную терминальную сессию открывать, чтобы, например, загрузить копию базы из файла.

И, наконец, хочу, чтобы результат запроса в виртуальной таблице полностью совпадал с результатом точно такого же вложенного запроса! А то с этими виртуальными таблицами постоянно какие-то сюрпризы: то строки вдруг исчезают при агрегатных функциях типа МАКСИМУМ, то в поле составного типа значение Справочник...ПустаяСсылка вдруг превращается в NULL - в результате простой перенос вложенного запроса в виртуальную таблицу выливается в многочасовую головоломку - почему же вдруг изменились результаты запроса.

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

(241) Тут должна помочь молитва "йелоупуки, йелоупуки, переставь нам с попы руки"

(243) Это просто поразительно, но в некоторых случаях достаточно поместить виртуальную таблицу в другую (промежуточную) виртуальную таблицу (ничего больше не делая!), и всё начинает правильно работать. :)

(244) Проблемы неадекватных запросов могут наблюдаться только в СУБД, отличных от файловой и mssql

(245) MSSQL 2008. На других не проверяла, не знаю.

(245) Кстати, в файловой это точно было.

(246) (247) Вы что - то упустили.

Вы - девушка? Вот это поворот!

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

В любой непонятной ситуации делай ТиИ

Пол мужской, достигла "просветления".
простой перенос вложенного запроса в виртуальную таблицу
P.S.
ушел спать в недоумении

А, ещё забыла добавить: очень хочется, чтобы 1С корректно работала с СУБД, и если уж не совсем исключила избыточные транзакции, то хотя бы отслеживала в агенте сервера некорректное их завершение/зависание и не допускала ситуаций, когда BEGIN TRANSACTION не имеет COMMIT TRANSACTION, и из-за вылета программы у одного пользователя приходится рестартовать целый сервер.

(252) таких ситуаций не бывает. sql всегда сделает rollback, даже если сервер 1С отвалится.

(253) То есть как это не бывает?
А что тогда было, когда SQL возвращал такую ошибку, и даже зайти в базу было проблематично, не говоря уже о попытках что-то там записать или даже прочитать?

(254) сессия sql подвисла.

(255) И чего бы ей подвисать вдруг?

(253)
Чисто теоретически, таких ситуаций не бывает, когда каждый клиент самостоятельно долбится на сервер. А у 1С же переиспользуемый пул коннектов, нмнип. Так что вполне возможная ситуация. Клиент сервера 1С начал транзакцию и умер. Сервер 1С отдал коннект к БД другому пользователю.

(257) Я говорю о том случае, если сервер 1С умрет (завершится штатно)

(257) А чего тебе не хватает в 1С?

(259)
"Ты ведь меня знаешь, Абдулла" (с)
Мне если что не в 1С не хватает, я себе сам сделаю :)

(260) А ведь потом это сделает 1С :-) Абидна, да?

(261)
Всё не сделает. Да и должен же их кто-то подпинывать личным примером. А то глядишь, до сих пор бы сидели без подсказок по параметром методов и подсветки текущей переменной. Вроде ничего не упустил, из того что "1С потом сделала". :)

(262) Пффф.
Хэши, Криптография, ДвоичныеДанные, Миллисекунды, Уведомления.

(263)
Это о чём? Речь вроде шла о наработках, которые сначала я сделаю, а потом 1С. Ничего из перечисленного я не делал.

(264) Аа, я думал - в общем.

(232)
Имхо, ЖР в базе данных - крайне сомнительное решение. Писать журнал обращений к базе данных в эту же базу данных - чем то напоминает бекап диска на этот же диск.
1С и так базу данных нагружает, зачем туда еще и журнал писать? Всегда журналы отдельно в файлики пишутся, в нормальных системах.

(266) 1С пишет в отдельный файлик - mySQL

(267)
sqlite так-то. И это я тоже считаю кривым решением. Журнал должен записываться в простой файл.

(268) Вам не угодишь, подумала 1С и сделала возможность выбора.

(269)
И это хорошо. А девушку в (232) это не устраивает.

Журнал должен иметь разделение по процессам, иначе получится, что, в общем случае, все натыкаются на взаимные блокировки из-за записи в один и тот же журнал.
А тому, кому хочется в базе - пусть и дальше хочется, 1С итак не быстрая, чтобы её ещё тормозить.

P.S. а мне хотелось бы нормальные указатели на функции, чтобы не нужно было везде пихать Выполнить.

(261) лол.. это как со снегопатом..
как там пели?

"- капец твоему снегопату, ща все на эклипс перейдем вот прям завтра"

гы гы гы гы гы гы...

шел третий год..

(272)
Не, в первом квартале 2017 вот уже точно. Таково было откровение.

А, вспомнил, что еще я в своё время реализовывал "в паблик"  - регэкспы, которые унутре 1С, как суслик, которого не видно, а он есть. Интересно, сколько еще пройдёт, пока "1С сделает"? На партнёрском форуме знаю, народ их периодически просит, но видать, "слушай Ваня свои "Валенки" и не выпендривайся".

оффтоп. кто был на партнерке, были новые откровения?

(273) судя по тому что я видел сегодня на партнерке - думаю что и к 2018 хрен сделают..

не говоря уже про то что более менее вменяемо работать это все начнет году к 2020...

Хочу возможность записи набора регистров накоплений сразу по нескольким регистраторам. Очень помогло бы при массовых обработках документов.

(266) Всё это так, но когда ЖР лежит в отдельном неструктурированном файле без индексов, это сильно осложняет работу с ним, всевозможные отборы и т.п.
Если пытаться представить компромиссный вариант, то действия, касаемые базы в целом могли бы фиксироваться отдельно, а действия с объектами базы - внутри самой базы.

(255)(258) Вот о том и речь, что процесс на сервере завис, а потом был принудительно закрыт, а SQL транзакцию не отменил.
Можно говорить, что это глюк SQL, но раз уж 1С работает с такой СУБД, то можно было бы это предусмотреть.

Хочу чтобы вместо малоинформативной надписи "Сбор данных..." в конфигураторе было оценочное время выполнения, что то вроде - "вы можете лечь поспать, раньше утра не закончу" и т.п. Уже даже самые тупые программы могут примерно оценивать время операции, но не 1С.

(279) Это тебе сначало в Мелкософт надо обратиться.

(278) Чудес не бывает.

(281) Если вы видите чудо в IT - вы просто что-то упустили. В IT не бывает случайных событий. Но вы можете оправдать свое невежество фразой "я перезагрузил и все заработало".

Хочу выборочное сравнение и объединение объектов конфигурации с внешним файлом конфигурации. Хотя-бы чтобы сравнивало только по захваченным в хранилище объектам.

(277)
Это у вас всё от недопонимания роли журнала регистрации.
В нормальных системах разделяют два процесса - запись логов и анализ логов. Обычно это делается так - логи кидаются простым текстом в обычные файлы (это самый быстрый метод),  а уж на эти файлы потом натравливается какая-либо программа анализа логов, которая выкручивает из них всякую статистику и прочую бигдату. К примеру - на сервере nginx пишет свои логи в файлики, в 6 утра cron'ом запускается logrotate, он  заводит новый файл лога, а на прошлый натравливается webalizer, и я с утра могу посмотреть всяческую статистику.

(284) Я думаю, индексов в mysql базе ЖР от 1С нет, либо они минимальны.
Да и немного 1С в ЖР пишет.

(122) > 9. анализ лиц покупателей, поддержка рекомендательных систем.

Это не работает.

+(286) разве что с базой МДВ повязать...

(284) Ключевые слова здесь - "В нормальных системах".
Здесь же ситуация такова, что анализатора по сути нет, и некоторые делают его сами (и ещё продают потом), но когда задачи по анализу не очень значительны, то вроде как и нет смысла тратить время на создание анализатора или дополнительного учёта.
И вот так возникает парадоксальная ситуация: нужно день потерять, чтобы раз в год за пять минут "долететь". Вот я и думаю, что 1С как-то это могла бы и получше организовать за столько-то лет.

(281) А что ты называешь чудесами? Закрытие транзакций от потерянных сессий? Это исключительно вопрос организации СУБД - если какая-то ситуация считается вероятной, то и средства для её обработки предлагаются. Если же в логике заложено, что "этого не может быть, потому что этого не должно быть", то и средств никаких не делается, и выхода из таких ситуаций нет.

Если же ты считаешь регламентное завершение зависших процессов в принципе неверным подходом, то предложи своё решение тогда.

(288) Начнём с того, что журнал регистрации или "лог-файл" - обычно просто текстовый файл, который читают, чтобы понять, что происходит в системе. Файл пишется последовательно и один раз, индексирование и структурирование только усложняет запись и увеличивает её время.
Почему не сделали анализатор и конвертер - вопрос к тем, кто в журнал пишет, так как нет никакого структурирования в записи, то будет записана каша, а её как не структурируй - получится фигня.
То, что сейчас 1С подменяет имена пользователей или сеансов ссылками на таблицу вместо строк - это просто сокращение объёма записи, так как имена сеансов и пользователей очень редко меняются.

(290) ЖР мог бы быть структурированным - туда же строго определённые данные пишутся, а не какие угодно. Однако в том формате, в каком он хранится, структуры как таковой нет.
Время записи в таблицу базы актуально лишь в файловом формате базы. А в SQL, например, запись нескольких записей в ещё одну таблицу внутри транзакции ничего принципиально не изменит.

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

(288)
>> Ключевые слова здесь - "В нормальных системах".
Но это же ветка со списком мечт. Почему не мечтать о "нормальной системе"?

(292) Вот только это и остаётся...

"Кроме этого поддерживается выгрузка журнала регистрации в формате XML, что может использоваться для последующего анализа выгруженных записей средствами встроенного языка."
http://v8.1c.ru/overview/Term_000000292.htm

(290) Помнится ЖР с релиза 8.3.5.1068 может хранится в SQLite, а это уже не текстовый файл, и работает это чуток побыстрее, чем текстовый файл...

(294)
Для анализа - быстрей. А для записи - медленней.

(295) Учитывая, что УФ все равно сильно неторопливы, то это еще нормально, до сих пор с ужасом вспоминаю как по пол часа ждал, когда же ЖР откликнется...

(296) Я ещё с семёрки вспоминаю, что копируешь журнал в другую папку, запускаешь анализатор (написанный на Си) и смотришь.
Боюсь, что с управляемыми формами, даже если время выгрузки посчитать, то всё равно будет быстрее, чем смотреть через 1С.

Конечно быстрее, но все-таки не такие тормоза, как раньше :-) Как мало для счастья надо :-)))