Вход | Регистрация
 

Динамическое обновление. Вопрос к Экспертам по тех. вопросам

Динамическое обновление. Вопрос к Экспертам по тех. вопросам
Я
   osa1C
 
19.09.20 - 01:51
Доброго всем времени и настроения!
  Имеется тестовая база, с подключением к хранилищу. Разработка и тестирование проводится в ней, также как и проверка конечным пользователем перед внедрением в основную конфигурацию... На самом деле база не одна, их много, все лежат на удаленном сервере, к которому разработчики не имеют доступа администратора, что и правильно.
  Нам, как разработчикам ЗАПРЕЩЕНО динамическое обновление тестовых баз, под страхом казни))). Но был поздний вечер и в тестовой базе были два пользователя, которые на 98,9% просто не закрыли пользовательский режим после тестирования и спокойно спят дома....
  Я делал доработку кода в ОбщемМодуле, причем нами написанном, при этом измененный код не требует реструкторизации данных. Даже к МодулюФормы код не цепляется.. не говоря про реквизиты. Короче мне надо было срочно обновиться. Что я и сделал динамически.... За что получил "нагоняй" от нашего руководителя.... И только потому что он "подслушал" разговор с другим разработчиком про дин.обновление.
   Ну и сам вопрос: ... Чем так может замучить сервер Динамическое обновление?
   etc
 
1 - 19.09.20 - 02:26
(0) секта отрицателей динамического обновления. Удивительно как раздутая проблема проявляющаяся в ничтожном проценте случаев может довести до истерии.
Не суди их строго. Если ты можешь в течении пары минут вывести базу из состояния ступора после неудачного обновления то тебе "не страшен серый волк".
   etc
 
2 - 19.09.20 - 02:27
(0) но пока ты в этом коллективе с их правилами придется жить
   osa1C
 
3 - 19.09.20 - 02:35
(1) Как насчёт временной блокировки хранилища?
   osa1C
 
4 - 19.09.20 - 02:38
(3) + я про нулевые файлы блокировки хранилища
   etc
 
5 - 19.09.20 - 02:43
(3,4) не понимаю про что ты поскольку работа с хранилищем это одно а динамическое обновление это другое. Динамическое обновление можно провести независимо от того подключена у тебя база к хранилищу, аутентифицирован ли ты в нем или захвачено что-то.
   tixis
 
6 - 19.09.20 - 02:43
а при чем тут хранилище и дин обновление базы?
   tixis
 
7 - 19.09.20 - 02:44
(6) это к  (3) (4)
   tixis
 
8 - 19.09.20 - 02:46
как БАЗА свзязана с ХРАНИЛИЩЕМ?
   etc
 
9 - 19.09.20 - 02:49
(0) на сколько ты помнишь у тебя есть три конфигурации - конфигурация БД, сохраненная конфигурация и редактируемая конфигурация (конфигурацию хранилища в расчет не берем). Динамическое обновление это замена конфигурации БД на сохраненную конфигурацию. Хранилище тебя ограничивает в возможностях работы с редактируемой конфигурацией и не более.
   etc
 
10 - 19.09.20 - 02:50
(0) и да, эксперта у меня нет поэтому можешь относиться к моим словам как просто к опыту отдельного человека.
   osa1C
 
11 - 19.09.20 - 03:59
(5) я честно тоже не понимаю, может я глуп или что то не беру в расчёт...поэтому и спрашиваю
   osa1C
 
12 - 19.09.20 - 04:04
(8) Хранилище для базы одно. Понятно что есть связь между рабочим хранилищем и разработческим Разработчик захватывает нужные ему объекты из хранилища, меняет, отдает на тест заказчику и после того как заказчик принял, отпускает в основное хранилище, с которого потом и обновляются рабочие конфигурации. Вроде это просто работа с хранилищем? )))
   osa1C
 
13 - 19.09.20 - 04:56
Подниму :) Хочется и мнения другие услышать... привет мск
   osa1C
 
15 - 19.09.20 - 05:07
(14) Расширения - мовитон, а снятие проблем заключается в в снятии блокировок.... или тупого удаления нулевых lock-ов
   osa1C
 
16 - 19.09.20 - 05:18
(14) Хорошо бы если при обновлении затронуты таблицы, но если код не трогает таблицы и данные (нет добаления/удаления реквизитов и их перезаполнения и т.д.) то в чем проблема динамического ?
   osa1C
 
17 - 19.09.20 - 05:19
(14) Я не спорю, я наоборот хочу понять
   rphosts
 
20 - 19.09.20 - 05:39
(18) угу из=-за кэша все проблемы... и они иной раз такие странные и разнообразные
   APXi
 
21 - 19.09.20 - 07:54
(18) как может пользовательский кэш на таблицу config?
   APXi
 
22 - 19.09.20 - 07:55
+21 влиять
   osa1C
 
23 - 19.09.20 - 08:03
(18) Ваше мнение, так сказать, услышано и принято на заметку, хочется услышать и другие мнения
   osa1C
 
24 - 19.09.20 - 08:08
(19) Негатива к расширениям нет... Этот инструмент можно и нужно использовать... но только не в моей ситуации. У меня франч и только список городов, которые мы поддерживаем на несколько страниц, а в каждом городе список предприятий... и уже там список баз... и базы не типовые!!! Какое расширение? Можно ли запомнить куда какое расширение и зачем подключено?
   Конструктор1С
 
25 - 19.09.20 - 08:13
(0) расскажи воему руководителю, что он застрял в стереотипах десятилетней давности
   Конструктор1С
 
26 - 19.09.20 - 08:17
(18) "бывает что из -за кривого скорее всего пользовательского кэша в config попадают битые данные"

Как ты себе это представляешь?
   Фрэнки
 
27 - 19.09.20 - 08:17
(25) он не расскажет. Он сам в плену стереотипов, т.к. отрицает святость Расширения
   Фрэнки
 
28 - 19.09.20 - 08:19
точнее, даже не самого Расширения , а вот тот самый термин - хотфиксы - он топикстартеру чужд и дик.
   osa1C
 
29 - 19.09.20 - 08:58
(28) вот именно нужен хотфикс... и не знаешь как это сделать. Потому как с пользователями связывается только менеджер-консультант, а его тоже уже нет на работе. И выкинуть залипших пользователей вроде не имеешь права... Но работу надо сегодня и сейчас отпустить в хранилище, чтобы ночью обновление прошло
   Фрэнки
 
30 - 19.09.20 - 09:14
(29) т.е. мы знаем, что в серьезных системах для установки хотфиксов применяются hooks (крючки, крюки). Их в систему нужно вколачивать заранее. Т.е. серьезная система вольностей не прощает.
В конфигурации 1С о наличии предустановленных гибридных хуков можно узнать по модулям переопределяемый_чего_там.
А там где код абсолютно плоский - там хуже всего, но возможности вколотить хук динамически все равно остаются.
Если где в коде есть хотя бы какие-нибудь вызовы процедур или функций, то их можно использовать эти вызовы для установки хуков,
т.е. закидываешь вызовы чего попало в Расширение с пометками перед, после, вместо ...

Вроде все просто.

з.ы.
А руководитель должен не просто выдавать волшебные пендали, но и в нужном направлении это делать - под зад, но влево или прямо или вправо :-)
Но не просто сверху вниз по голове хрясь и сиди на попе ровно, никуда не двигаясь дальше.
 
 Рекламное место пустует
   Конструктор1С
 
32 - 19.09.20 - 11:09
(31) а как ты находишь якобы связь между клиентским кешем и происходящим в config?
   Конструктор1С
 
33 - 19.09.20 - 11:10
(29) так ты же пишешь про тестовую базу. Неужели твоё руководство так опасается за тестовый стенд?
   etc
 
34 - 19.09.20 - 13:00
(32) он наверно имеет ввиду когда конфа на клиенте не обновилась и отличается от серверной но об этом ничего не знает. Я один раз лет 10 назад видел ситуацию когда при отладке сеанса пользователя у меня отладчик прыгал по несуществующим строкам.
   etc
 
35 - 19.09.20 - 13:02
(34)+ причем пользователь перезаходил в базу
   rphosts
 
37 - 19.09.20 - 17:37
(21) один раз в прошлой конторе во время дин. обновления раб. базы был очень кратковременный разрыв сети.... очень повлияло...
   Конструктор1С
 
38 - 19.09.20 - 17:39
(36) совершенно не логично, чтобы 1с тащила данные из кэша на диске для сохранения конфигурации
   palsergeich
 
39 - 19.09.20 - 18:56
(0) Можно 1000 раз обновиться динамически и не понять почему так на него ругаются.
А на 1001 раз поймать проблем.
До сих пор - шанс того что база будет порушена <> 0.
А это время на восстановление и прочее.
Или будут какие нибудь экзотические проблемы, например отвал отладки - в 8.3.16, 17 - неоднократно ловил на тестовой. Лечится или чисткой кеша или полные логаут из системы - а это всё время.
Задача руководителя одна из - обеспечить беспередойное функционирование.
Динамическое обновление по разным причинам может этому помешать.
Банальный отрост таблицы config раком может нагнуть SQL сервер, и страдать будут все из-за одного.
   vde69
 
40 - 19.09.20 - 21:57
(0) динамическое обновление имеет только один недостаток (но очень неприятный) - ресинхронизации пользовательского кэша с конфигурацией базы.

Если пользователи адекватные - можно динамически накатывать, если это "большие дядьки" - то лучше не надо....
   Ёпрст
 
41 - 19.09.20 - 22:02
(40) адекватные, это которые на предложение перезапуска ДА отвечают ? :)
   vde69
 
42 - 19.09.20 - 22:08
(41) именно и в добавок не оставляют открытые сесии на ночь :)

вообще в случае (0) надо было через консоль выкинуть тех двоих и спокойно обновить
   Ёпрст
 
43 - 19.09.20 - 22:15
(42) ну, зависит всё же чего там в демоническом обновлении, одно дело кнопочки на форме подвигать или ошибку в коде исправить, другое дело, исправление логики в проведении дока, вот тут да, есть засада, когда могут доки проводится с разными алгоритмами.
А так, демоническое обновление не так и плохо. Ну, повесить триггер токма на табличку конфы, на всякий при любом сохранении и привет
   Cthulhu
 
44 - 20.09.20 - 01:30
решалось полуадминистративно раз и навсегда (в семерке еще).
разрабатывался регламент работы в ИБ с расписанием для разных отделов.
- для отделов, которые работают строго по расписанию (продажники, кладовщики, и т.п.) - безусловный запрет на работу в нерабочее время
- для отделов. в которых возможна работа в нерабочее время - отдельный регламент доступа в базу в нерабочее время - подача заявки и т.д.
- т.н. "ургентных" пользователей - в отдельный список. по нему - возможность работы в любое время с обязательным внесением соответствующей записи в реестр (для админа) со всеми контактами, с описанием вида работы и временем начала - конца.
регламент - всем для ознакомления под роспись. именно всем, без исключений.
начиная с этого времени вопросов и проблем с доступом к базе не возникало. админ с чистой совестью сверял подключения с регламентом и реестром, все что не упомянуто в них - с чистой совестью убивал, все довольны. был случай, когда отрубили диру сеанс и он введенные данные и какие-то отчеты потерял. после истерики - проверились по реестру, в котором его работ не нашли, перечитали регламент - все верно, дир сам виноват, извинился даже (перед этим истерил жостко)...
не надо решать программно то, что можно и должно решать административно.
   rphosts
 
45 - 20.09.20 - 02:40
(44) есть ряд работников которые часто перерабатывают и продажники часто из таких. Имхо, достаточно регламентировать ежедневные тех.окна. Всех кто не вышел - выносить из базы ибо регламент есть регламент
   ГдеСобакаЗарыта
 
46 - 20.09.20 - 04:21
(0) Можно ж было просто добавить произвольный объект и обновить с выкидышем пользователей.
   МимохожийОднако
 
47 - 20.09.20 - 07:34
(42) Это самое оптимальное. Плачут и не понимают, что произошло только двое. А при проблемах динамическое - плачет большинство.
   Web00001
 
48 - 20.09.20 - 07:42
(0)Был случай на 8.1, может уже исправили и такое не может больше произойти, а может и нет. Баз РИБ, были проведено обновление конфигурации динамически на всех пяти базах. Обновили и продолжили работать. Где-то через неделю обнаружили что в одной из баз, не хватает куска кода, в остальных все ок. Этот модуль не трогали очень давно. При этом обмены обходят и 1С считает базы идентичными. Было не очень приятно и немного тревожно) кабы чего не вышло, что еще похерилось о чем я не узнал?
   youalex
 
49 - 20.09.20 - 07:47
Странно, что у разработчиков нет возможности "выкидывать" пользователей из тестовой базы. Хотя бы по регламенту.
   osa1C
 
50 - 20.09.20 - 08:05
(30) В смысле "волшебных пендалей" у нас всё ровно. Есть ещё и "волшебные пряники". Пенделя дают ему, руководителю моему, а он не программист, консультант. А он пендель передаёт по цепочке.
   Отсюда в принципе и вопрос и сама ветка. Хочется умных мыслей, что дин.обновление не так уж и плохо при умном использовании. А просто "не делай так, потому что так нельзя, а нельзя однозначно и без объяснений" - это тупо.
   osa1C
 
51 - 20.09.20 - 08:08
(33) Разговор о том, что после динамических обновлений у клиента падает сервер. Не база! , проблемы на сервере мне не понятные. Я же не эксперт по хехнологической части )))
   Фрэнки
 
52 - 20.09.20 - 08:44
(51) можно долго долго разбираться с этими всеми тонкостями... Дам изложение своими словами.

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

Механизм Расширений игнорирует наличие кэша конфигурации. По всей видимости, было сделано предположение, что объем дописок в Расширениях относительно небольшой, а потому взамен кэша возможно считывание Расширения прямо и непосредственно из того, что сохранено в базу (т.е. Расширение работает без кэша - это мое предположение и упрощение)

Более того, взаимодействие Расширения с платформой несколько отличается от поведения просто Конфигурации с платформой, особенно, когда работает все в режиме 1С Клиент-Сервер. В файловой не так, а по своему, но все равно не так, как у конфигурации без расширения.

В результате имеем несколько другое поведение, скажем так, платформы и сервера платформы в процессе работы с базой.
   Фрэнки
 
53 - 20.09.20 - 08:45
Обращаю внимание, что о наличии кэша на клиенте обычно помнят все, а вот, что он есть и на _сервере_ - забывают
   Конструктор1С
 
54 - 20.09.20 - 09:00
Массовые проблемы с кэшем при динамическом обновлении были ещё на 8.1. Уже на 8.2 их количество резко уменьшилось. А на последних версиях платформы это вообще экзотика
   Конструктор1С
 
55 - 20.09.20 - 09:13
+ самые проблемы с дин. обновлением были на файловых базах, клиент-серверные меньше спотыкались
   ДенисЧ
 
56 - 20.09.20 - 09:15
(55) А у меня наоборот.. На файловых ни разу. На серверных встречалось
   osa1C
 
57 - 20.09.20 - 10:15
(52) Надеюсь разработчики 1С прочитают твои мысли.... Нужно же им что то читать на досуге. И сделают верные выводы
   Волшебник
 
58 - 20.09.20 - 10:18
(53) Кэш хранится в 3 (трёх!) местах
   Фрэнки
 
59 - 20.09.20 - 10:37
(58) но это же разный кэш :-)

Я бы его хранил просто в базе и ее конфигурации, но...
Впрочем, Расширения там и хранятся без кэша, судя по их поведению
   experimentator76
 
60 - 20.09.20 - 10:54
(0) лучше дин.обновлением не увлекаться, потому что раньше случалась проблема в том, что в базу потом было не зайти без чистки SQL-таблиц с мусором от дин.обновления. с неадекватным кэшем сталкивался почему-то только на базах где используются обычные "неуправляемые" формы. там - да - лучше станцевать с бубном для тех.перерыва, выгнать всех через консоль и т.п.
 
 Рекламное место пустует
   Cyberhawk
 
61 - 20.09.20 - 14:27
Тебя посадят, а ты не воруй (с)
Базы рухнут, а ты не динамь


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.