Хочу поделиться своим опытом работы с хранилищем конфигураций.
Некоторое время назад, мы с коллегой стали пользоваться хранилищем конфигураций, чтобы синхронизировать свои изменения, и столкнулись с тем, что иногда написанный код терялся, хотя гарантированно помещался в хранилищище.
Искал решение в интернете, но не нашел четкого ответа почему и как это происходит.
После экспериментов обнаружил, что если ты вносишь изменения в захваченный объект конфигурации, динамически обновляешь конфигурацию, а потом коммитишь изменения, то в хранилище помещается версия на момент захвата.
Если внести изменения, закоммитить их, а потом динамически обновить - тогда все нормально.
Народ и раньше предполагал, что это связанно с динамическим обновлением, но не был уверен в этом на 100%.
Некоторое время назад, мы с коллегой стали пользоваться хранилищем конфигураций, чтобы синхронизировать свои изменения, и столкнулись с тем, что иногда написанный код терялся, хотя гарантированно помещался в хранилищище.
Искал решение в интернете, но не нашел четкого ответа почему и как это происходит.
После экспериментов обнаружил, что если ты вносишь изменения в захваченный объект конфигурации, динамически обновляешь конфигурацию, а потом коммитишь изменения, то в хранилище помещается версия на момент захвата.
Если внести изменения, закоммитить их, а потом динамически обновить - тогда все нормально.
Народ и раньше предполагал, что это связанно с динамическим обновлением, но не был уверен в этом на 100%.
По теме из базы знаний
- Файловые базы *.1CD. Физическая структура. Восстановление.
- Интеграция сценарного тестирования в процесс разработки
- Синхронизация хранилища 1С и git-репозитория с применением OneScript и Gitsync. Методика и пошаговая инструкция для создания скрипта и его регулярного запуска
- Надежная регистрация изменений. Версионирование объектов. Аудит. Все средствами SQL Server
- Полезные хоткеи конфигуратора
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Xershi, да-да, обсуждалось и всегда встречаются примерно следующего содержания тексты:
В данном посте я указываю конкретную последовательность действий, приводящую к потере кода, и указываю другую последовательность действий, которая позволяет избежать этой ошибки.
Как следует поступать в случае, когда после помещения объекта в хранилище пропадают внесенные изменения?
Однозначного решения проблемы не обнаружено, однако существует набор действий, которые зачастую помогают в этом случае. ...
Однозначного решения проблемы не обнаружено, однако существует набор действий, которые зачастую помогают в этом случае. ...
В данном посте я указываю конкретную последовательность действий, приводящую к потере кода, и указываю другую последовательность действий, которая позволяет избежать этой ошибки.
(1) shsa, это попытка описать свои ощущения... Код пропадает где и когда?
Могу предположить, что новый код не появляется у приятеля, а он также комитет свой код уже без первоначального кода.
Как было сказано, 99% всех проблем с локальным кем хранилища. После захвата хранилища нужно принудительной получить данные из хранилища - это пересоздаст локальный кеш. Тогда и данные теряться не будут.
Могу предположить, что новый код не появляется у приятеля, а он также комитет свой код уже без первоначального кода.
Как было сказано, 99% всех проблем с локальным кем хранилища. После захвата хранилища нужно принудительной получить данные из хранилища - это пересоздаст локальный кеш. Тогда и данные теряться не будут.
(1) shsa, у нас рабочая база не связана с хранилищем. Каждый делает работу на своей файловой, а когда надо кто-то один обновляет свою конфу из хранилища и выгружает CF. С этого CF-ника и накатываются изменения на рабочую базу. При обновлении механизм конечно другой, но смысл прежний: рабочая база не завязана на хранилище!
Мы на инфостарте перед тем как использовать почитали и где-то была именно такая рекомендация (не завязывать рабочую базу на хранилище).
Может и вам стоит так делать?
Мы на инфостарте перед тем как использовать почитали и где-то была именно такая рекомендация (не завязывать рабочую базу на хранилище).
Может и вам стоит так делать?
(7) klinval, в корне не верный принцип. При частой модификации больших блоков кода. Вы убьетесь обновляться! Стоит грамотно научиться пользоваться хранилищем, как скорость внедрения возрастет в разы!
(8) shsa, вы только выявили одно из. Динамическое обновление тоже не страшно, если делать регулярно чистку кэша. Но это уже не о пропадании кода вопрос.
(13) spacecraft, в такой последовательности нет ничего криминального. Такая ситуация может проявиться позже. Когда у вас несколько раз один объект будет помещен в хранилище без получения всех последовательных помещений.
Насоздавайте баз и по кругу в одном модуле навносите код. Затем когда вернетесь захватите объет, а не получите. Результат гарантирован!
(8) shsa, вы только выявили одно из. Динамическое обновление тоже не страшно, если делать регулярно чистку кэша. Но это уже не о пропадании кода вопрос.
(13) spacecraft, в такой последовательности нет ничего криминального. Такая ситуация может проявиться позже. Когда у вас несколько раз один объект будет помещен в хранилище без получения всех последовательных помещений.
Насоздавайте баз и по кругу в одном модуле навносите код. Затем когда вернетесь захватите объет, а не получите. Результат гарантирован!
(14) Xershi,
Причем другая последовательность действий:
Я просто не понимаю этих крайностей. Есть проблема, есть как минимум 3 варианта решения. И почему-то каждый считает ТОЛЬКО СВОЙ вариант правильным?! Лично я все варианты "намотал на ус" и если что подберу в конкретной ситуации мне удобный. Пока мне удобнее не подключать рабочую базу к хранилищу.
Меня пока не напрягает раз в день (иногда раз в неделю) выгружать в cf-ник изменения и с него накатывать на рабочую базу. Минус данного способа очевиден: приходится тратить время на выгрузку cf-ника. Но это время не обязательно же бесполезно пялится в экран глядя на прогресс-бар).
Но этот способ даёт также и определенные преимущества:
1) Все нюансы/косяки подключения хранилища к рабочей базе можно не изучать.
2) Дополнительный аудит внесенных изменений в базу. Бывает что на этом последнем этапе, когда свою работу (или работу коллеги) видишь в сравнении До-После, находятся не очевидные вещи, которые ты ранее не замечал.
Что касается способа:
С чисткой кэша пока мне не ясно: а что всё-таки чистить? herfis и Xershi можете конкретней описать каким методом вы пользуетесь (батничек в планировщике, ключ запуска 1С и т.д.)?
(7) klinval, в корне не верный принцип. При частой модификации больших блоков кода. Вы убьетесь обновляться! Стоит грамотно научиться пользоваться хранилищем, как скорость внедрения возрастет в разы!
А в "корне правильный" принцип как я понимаю:
Динамическое обновление тоже не страшно, если делать регулярно чистку кэша.
Т.е. заранее знать, что есть в подключении к хранилищу рабочей базы минусы и уметь обходить эти минусы - это правильно, а создать ситуацию когда эти минусы тебя не тревожат - это "в корне не верный принцип"...
Причем другая последовательность действий:
Если внести изменения, закоммитить их, а потом динамически обновить - тогда все нормально.
Вами тоже отвергается как не правильная.
Я просто не понимаю этих крайностей. Есть проблема, есть как минимум 3 варианта решения. И почему-то каждый считает ТОЛЬКО СВОЙ вариант правильным?! Лично я все варианты "намотал на ус" и если что подберу в конкретной ситуации мне удобный. Пока мне удобнее не подключать рабочую базу к хранилищу.
Меня пока не напрягает раз в день (иногда раз в неделю) выгружать в cf-ник изменения и с него накатывать на рабочую базу. Минус данного способа очевиден: приходится тратить время на выгрузку cf-ника. Но это время не обязательно же бесполезно пялится в экран глядя на прогресс-бар).
Но этот способ даёт также и определенные преимущества:
1) Все нюансы/косяки подключения хранилища к рабочей базе можно не изучать.
2) Дополнительный аудит внесенных изменений в базу. Бывает что на этом последнем этапе, когда свою работу (или работу коллеги) видишь в сравнении До-После, находятся не очевидные вещи, которые ты ранее не замечал.
Что касается способа:
Если внести изменения, закоммитить их, а потом динамически обновить - тогда все нормально.
Минусом является то, что в следующей версии платформы этот баг может вылезти даже в этой последовательности действий.
С чисткой кэша пока мне не ясно: а что всё-таки чистить? herfis и Xershi можете конкретней описать каким методом вы пользуетесь (батничек в планировщике, ключ запуска 1С и т.д.)?
(23) klinval, я чистку кэша использую только для рабочей базы, чтобы проблем у пользователей не было. А т.к. я по плану работаю с хранилищем, то чистить его кэш мне не приходится. Как и кэш базы для разработок.
Пишите код правильно и большинство проблем отпадет. Ну а если потом найдут косяк, то также легко откатить базу или сразу же поместить новое обновление!
Пишите код правильно и большинство проблем отпадет. Ну а если потом найдут косяк, то также легко откатить базу или сразу же поместить новое обновление!
(25) Xershi,
Ну так вы пишите что у вас есть методика. В чём она заключается? У вас есть какой-то батничек который сам запускается (или вы вручную его запускаете с определенной периодичностью). Или вы на постоянку записали ключ /ClearCache на запуск рабочей базы? В чём методика то состоит?
Ошибки в программировании неизбежны! Есть даже исследования о плотности ошибок на 1000 строк кода, есть рекомендации как уменьшить количество ошибок, но нет ни у кого 100% метода полностью избежать ошибок... Сравнение в конце дня (недели) в режиме До-После позволяет уменьшить количество ошибок. В идеале это сравнение должен делать другой программист с полным вниканием, но не всегда так получается. Это позволяет уменьшить количество откатов и динамических обновлений посередь дня.
Конечно если программистов 50 человек никто не осилит вникнуть в работу каждого, поэтому нужны что-то вроде инспекций кода (см. Макконнелл «Совершенный код»). Полноценные инспекции для небольших отделов это избыточно и достаточно мини-инспекций при сравнении/обновлении.
Я понимаю, что у всех свои нюансы, потому стараюсь не преподносить свою точку зрения как единственно правильную. Просто озвучил один из вариантов работы. Готов выслушать и другие - вдруг лучше будут, тогда есть смысл что-то поменять и в своей работе. Но пока сильных аргументов в пользу подключения рабочей базы к хранилищу не услышал.
я чистку кэша использую только для рабочей базы, чтобы проблем у пользователей не было. А т.к. я по плану работаю с хранилищем, то чистить его кэш мне не приходится. Как и кэш базы для разработок.
Ну так вы пишите что у вас есть методика. В чём она заключается? У вас есть какой-то батничек который сам запускается (или вы вручную его запускаете с определенной периодичностью). Или вы на постоянку записали ключ /ClearCache на запуск рабочей базы? В чём методика то состоит?
Пишите код правильно и большинство проблем отпадет. Ну а если потом найдут косяк, то также легко откатить базу или сразу же поместить новое обновление!
Ошибки в программировании неизбежны! Есть даже исследования о плотности ошибок на 1000 строк кода, есть рекомендации как уменьшить количество ошибок, но нет ни у кого 100% метода полностью избежать ошибок... Сравнение в конце дня (недели) в режиме До-После позволяет уменьшить количество ошибок. В идеале это сравнение должен делать другой программист с полным вниканием, но не всегда так получается. Это позволяет уменьшить количество откатов и динамических обновлений посередь дня.
Конечно если программистов 50 человек никто не осилит вникнуть в работу каждого, поэтому нужны что-то вроде инспекций кода (см. Макконнелл «Совершенный код»). Полноценные инспекции для небольших отделов это избыточно и достаточно мини-инспекций при сравнении/обновлении.
Я понимаю, что у всех свои нюансы, потому стараюсь не преподносить свою точку зрения как единственно правильную. Просто озвучил один из вариантов работы. Готов выслушать и другие - вдруг лучше будут, тогда есть смысл что-то поменять и в своей работе. Но пока сильных аргументов в пользу подключения рабочей базы к хранилищу не услышал.
(26) klinval,
Ну так вы пишите что у вас есть методика. В чём она заключается? У вас есть какой-то батничек который сам запускается (или вы вручную его запускаете с определенной периодичностью). Или вы на постоянку записали ключ /ClearCache на запуск рабочей базы? В чём методика то состоит?
я про методику работы с хранилищем. Это получение объектов из хранилища до пустого результата и только потом захват. В большинстве случаем захвата достаточно, но когда нет, тогда будет косяк.
(23) klinval,
Вы что-то не то намотали. Отказ от подключения рабочей базы к хранилищу сабжевых проблем не решает никак. Все проблемы со слетом локального кэша вы словите раньше и если отсутствует аудит изменений, то точно также зальете в рабочую из своего cf. То есть профита никакого, вы только теряете в удобстве. А аудит с хранилищем даже удобнее и проще. Просто нужно чтобы точно также один человек этим занимался.
ИМХО, не подключать рабочую к хранилищу имеет смысл исходя из совершенно других причин. Когда имеет смысл использовать сложные схемы дистрибуции. Как правило - с использованием поставок. Если просто пара/тройка разрабов пилят одну конфу на фикси - вот никакого смысла не вижу. Вообще.
ЗЫ. По поводу кэша. Стыдно признаться, но сейчас я на него тупо забил. Потому как проблемы вылазят редко и не хочется усложнять себе жизнь. Обычно опа ловится на этапе аудита при заливке изменений в рабочую. И когда проблема возникает, почему-то всегда оказывается проще руками каталоги почистить, чем скрипт искать :) На текущей работе специфика такая, что слишком часто приходится баловаться динамическим обновлением. На прошлой удалось от него полностью отказаться.
"Лично я все варианты "намотал на ус" и если что подберу в конкретной ситуации мне удобный. Пока мне удобнее не подключать рабочую базу к хранилищу"
Вы что-то не то намотали. Отказ от подключения рабочей базы к хранилищу сабжевых проблем не решает никак. Все проблемы со слетом локального кэша вы словите раньше и если отсутствует аудит изменений, то точно также зальете в рабочую из своего cf. То есть профита никакого, вы только теряете в удобстве. А аудит с хранилищем даже удобнее и проще. Просто нужно чтобы точно также один человек этим занимался.
ИМХО, не подключать рабочую к хранилищу имеет смысл исходя из совершенно других причин. Когда имеет смысл использовать сложные схемы дистрибуции. Как правило - с использованием поставок. Если просто пара/тройка разрабов пилят одну конфу на фикси - вот никакого смысла не вижу. Вообще.
ЗЫ. По поводу кэша. Стыдно признаться, но сейчас я на него тупо забил. Потому как проблемы вылазят редко и не хочется усложнять себе жизнь. Обычно опа ловится на этапе аудита при заливке изменений в рабочую. И когда проблема возникает, почему-то всегда оказывается проще руками каталоги почистить, чем скрипт искать :) На текущей работе специфика такая, что слишком часто приходится баловаться динамическим обновлением. На прошлой удалось от него полностью отказаться.
(27) herfis,
У нас проблем указанных в теме не было ни разу. Код не терялся. Может он не терялся потому что не было смысла вносить динамически в локальную базу?)) Если бы рабочую базу подключили к хранилищу - тогда пришлось бы динамически вносить из хранилища и возможно возникли какие-нибудь проблемы с потерей кода.
Чисто теоретически вы правы: моя рекомендация не решает проблемы потери кода в хранилище при динамическом обновлении, но если отказаться от подключения рабочей базы к хранилищу отпадёт необходимость динамического внесения изменений в базе с подключением к хранилищу.
(29) herfis,
В ИТС есть статья, где они разъясняют как и когда нужно/можно пользоваться несколькими хранилищами. Например там есть что-то типа: если идёт проект то по нему можно открыть второе хранилище. После окончания проекта результат заливается на основное хранилище... Мы это не используем.
Отказ от подключения рабочей базы к хранилищу сабжевых проблем не решает никак. Все проблемы со слетом локального кэша вы словите раньше и если отсутствует аудит изменений, то точно также зальете в рабочую из своего cf. То есть профита никакого, вы только теряете в удобстве.
У нас проблем указанных в теме не было ни разу. Код не терялся. Может он не терялся потому что не было смысла вносить динамически в локальную базу?)) Если бы рабочую базу подключили к хранилищу - тогда пришлось бы динамически вносить из хранилища и возможно возникли какие-нибудь проблемы с потерей кода.
Чисто теоретически вы правы: моя рекомендация не решает проблемы потери кода в хранилище при динамическом обновлении, но если отказаться от подключения рабочей базы к хранилищу отпадёт необходимость динамического внесения изменений в базе с подключением к хранилищу.
(29) herfis,
В ИТС есть статья, где они разъясняют как и когда нужно/можно пользоваться несколькими хранилищами. Например там есть что-то типа: если идёт проект то по нему можно открыть второе хранилище. После окончания проекта результат заливается на основное хранилище... Мы это не используем.
(32) klinval, "Если бы рабочую базу подключили к хранилищу - тогда пришлось бы динамически вносить из хранилища и возможно возникли какие-нибудь проблемы с потерей кода."
Да нет никакой разницы между обновлением из cf и из хранилища. Понапридумывают предрассудков а потом распространяют.
В момент загрузки обновлений в рабочую конфу из хранилища уже глубоко фиолетово чего, где и как "динамически" где было.
Получается тот же самый cf путем слепка данных хранилища и объединяется с конфой. Все тоже самое. А с проблемами сбоя локального кэша вы не сталкивались судя по всему просто потому, что редко используете динамическое обновление конфигурации. И хранилище тут абсолютно не при чем. Сама технология работы хранилища абсолютно надежна (во всяком случае, за долгие годы напряженной работы я НИ РАЗУ не сталкивался с проблемами, где оно было источником) и при обновлении через хранилище выполняются более глубокие и строгие проверки, чем при обычном объединении.
(33) klinval, Нормально отработает. Конфигурации поставщика тоже заезжают в хранилище как часть свойств конфигурации в целом (корень, короче, для этого должен быть захвачен).
Типовой в хранилище нет, но есть нетиповая на БСП, где подсистемы БСП на поддержке и я их регулярно обновляю. Там даже две конфигурации поставщика одновременно поддерживается - БСП и "Инструменты разработчика" - их тоже пару раз обновлял через поддержку.
Да нет никакой разницы между обновлением из cf и из хранилища. Понапридумывают предрассудков а потом распространяют.
В момент загрузки обновлений в рабочую конфу из хранилища уже глубоко фиолетово чего, где и как "динамически" где было.
Получается тот же самый cf путем слепка данных хранилища и объединяется с конфой. Все тоже самое. А с проблемами сбоя локального кэша вы не сталкивались судя по всему просто потому, что редко используете динамическое обновление конфигурации. И хранилище тут абсолютно не при чем. Сама технология работы хранилища абсолютно надежна (во всяком случае, за долгие годы напряженной работы я НИ РАЗУ не сталкивался с проблемами, где оно было источником) и при обновлении через хранилище выполняются более глубокие и строгие проверки, чем при обычном объединении.
(33) klinval, Нормально отработает. Конфигурации поставщика тоже заезжают в хранилище как часть свойств конфигурации в целом (корень, короче, для этого должен быть захвачен).
Типовой в хранилище нет, но есть нетиповая на БСП, где подсистемы БСП на поддержке и я их регулярно обновляю. Там даже две конфигурации поставщика одновременно поддерживается - БСП и "Инструменты разработчика" - их тоже пару раз обновлял через поддержку.
(38) herfis,
Правильно я понял в чём проблема темы: вносится изменения в рабочую базу динамически. Эти изменения туда корректно попадают. Потом конфа не закрывается и тут-же заливаются данные в хранилище, но туда попадают данные из локального кэша (который в момент захвата создался и не обновился после динамического обновления)?
P.S. и да мы стараемся как можно реже динамически обновлять. Когда можно даже прибегаем к возможности ручного изменения значения переменной в отладке. Например отказ было "Истина", но мы знаем что косяк в проверке, делаем в отладке Отказ="Ложь", но это только если документов не много.
(33) klinval, Нормально отработает.
спасибо за ответ, получает опыт у кого-то всё-таки есть в обновлении конфы на поддержке через хранилище.
Да нет никакой разницы между обновлением из cf и из хранилища. Понапридумывают предрассудков а потом распространяют.
В момент загрузки обновлений в рабочую конфу из хранилища уже глубоко фиолетово чего, где и как "динамически" где было.
Получается тот же самый cf путем слепка данных хранилища и объединяется с конфой. Все тоже самое. А с проблемами сбоя локального кэша вы не сталкивались судя по всему просто потому, что редко используете динамическое обновление конфигурации. И хранилище тут абсолютно не при чем. Сама технология работы хранилища абсолютно надежна (во всяком случае, за долгие годы напряженной работы я НИ РАЗУ не сталкивался с проблемами, где оно было источником) и при обновлении через хранилище выполняются более глубокие и строгие проверки, чем при обычном объединении.
В момент загрузки обновлений в рабочую конфу из хранилища уже глубоко фиолетово чего, где и как "динамически" где было.
Получается тот же самый cf путем слепка данных хранилища и объединяется с конфой. Все тоже самое. А с проблемами сбоя локального кэша вы не сталкивались судя по всему просто потому, что редко используете динамическое обновление конфигурации. И хранилище тут абсолютно не при чем. Сама технология работы хранилища абсолютно надежна (во всяком случае, за долгие годы напряженной работы я НИ РАЗУ не сталкивался с проблемами, где оно было источником) и при обновлении через хранилище выполняются более глубокие и строгие проверки, чем при обычном объединении.
Правильно я понял в чём проблема темы: вносится изменения в рабочую базу динамически. Эти изменения туда корректно попадают. Потом конфа не закрывается и тут-же заливаются данные в хранилище, но туда попадают данные из локального кэша (который в момент захвата создался и не обновился после динамического обновления)?
P.S. и да мы стараемся как можно реже динамически обновлять. Когда можно даже прибегаем к возможности ручного изменения значения переменной в отладке. Например отказ было "Истина", но мы знаем что косяк в проверке, делаем в отладке Отказ="Ложь", но это только если документов не много.
(41) klinval,
Судя по описанию, что-то вроде этого. Но для меня такое поведение достаточно странно. Ведь если кеш был сбойный и в хранилище пошли старые данные из кэша, то как можно было это позже не заметить? Разве что после этого кэш таки обновляется в какой-то момент. Если это в самом деле так, то готов согласиться с вами, что такая неприятность больше связана с работой именно с хранилищем. Подозреваю, что у нас это не проявлялось, так как все привыкли работая в тестовых базах не использовать динамическое обновление, ведь там это не имеет особого смысла. Только иногда на рабочей используется. А на рабочей вся работа с хранилищем обычно сведена к получению новых данных из хранилища и все. Т.е. на этом этапе, если помещенные данные в хранилище корректны, уже никаких сбоев в самой базе быть не может, даже если кэш сбойный. Потому как кэш не должен участвовать в заливке изменений из хранилища в основную конфу. Он должен как раз обновиться по результатам. Если не обновится - это должно повлиять только на работу этого конкретного клиента, а база должна остаться целостной. Припоминаю, что пару раз когда были таки траблы с целостностью, о которых я упоминал - выполнялись серии экстренных правок прямо на рабочей базе, с динамическим обновлением ессно :)
Так что предлагаю вам безопасную схему работы через хранилище - рабочую только обновлять из хранилища. Это даст гарантию целостности рабочей базы при любых сбоях локальных кэшей. Если перед обновлением делать ревизию заливаемых изменений - это даст контроль над помещенными в хранилище изменениями. Ревизия делается очень просто - путем сравнения конфигураций, там можно выбрать вариант сравнения основной конфы и конфы хранилища, причем даже с выбранной версией. Сравнение выполняется довольно быстро, т.к. идет по внутренним идентификаторам (хранилище гарантирует одинаковость внутренних идентификаторов метаданных во всех клонах баз). Если не делать динамическое обновление в девелоперских базах, то там и сбоев кэша не будет в принципе. Из плюшек - откат изменений при необходимости делается очень просто. Про единую историю изменений я уже молчу. Если внятно комментировать каждый коммит, то история разработки превращается в открытую книгу. Да что я тут говорю. Расписывать достоинства VCS это даже как-то глупо, даже такой как в 1С. Настолько их много и настолько они очевидны. В 8.3, кстати, сделали возможность фактически мгновенно сравнивать разные версии модулей одного объекта, без построения полных снэпшотов. За что им огромный поклон. Большинство вопросов, что, откуда, когда взялось и кем внесено - решаются очень быстро и удобно.
Правильно я понял в чём проблема темы: вносится изменения в рабочую базу динамически. Эти изменения туда корректно попадают. Потом конфа не закрывается и тут-же заливаются данные в хранилище, но туда попадают данные из локального кэша (который в момент захвата создался и не обновился после динамического обновления)? Судя по описанию, что-то вроде этого. Но для меня такое поведение достаточно странно. Ведь если кеш был сбойный и в хранилище пошли старые данные из кэша, то как можно было это позже не заметить? Разве что после этого кэш таки обновляется в какой-то момент. Если это в самом деле так, то готов согласиться с вами, что такая неприятность больше связана с работой именно с хранилищем. Подозреваю, что у нас это не проявлялось, так как все привыкли работая в тестовых базах не использовать динамическое обновление, ведь там это не имеет особого смысла. Только иногда на рабочей используется. А на рабочей вся работа с хранилищем обычно сведена к получению новых данных из хранилища и все. Т.е. на этом этапе, если помещенные данные в хранилище корректны, уже никаких сбоев в самой базе быть не может, даже если кэш сбойный. Потому как кэш не должен участвовать в заливке изменений из хранилища в основную конфу. Он должен как раз обновиться по результатам. Если не обновится - это должно повлиять только на работу этого конкретного клиента, а база должна остаться целостной. Припоминаю, что пару раз когда были таки траблы с целостностью, о которых я упоминал - выполнялись серии экстренных правок прямо на рабочей базе, с динамическим обновлением ессно :)
Так что предлагаю вам безопасную схему работы через хранилище - рабочую только обновлять из хранилища. Это даст гарантию целостности рабочей базы при любых сбоях локальных кэшей. Если перед обновлением делать ревизию заливаемых изменений - это даст контроль над помещенными в хранилище изменениями. Ревизия делается очень просто - путем сравнения конфигураций, там можно выбрать вариант сравнения основной конфы и конфы хранилища, причем даже с выбранной версией. Сравнение выполняется довольно быстро, т.к. идет по внутренним идентификаторам (хранилище гарантирует одинаковость внутренних идентификаторов метаданных во всех клонах баз). Если не делать динамическое обновление в девелоперских базах, то там и сбоев кэша не будет в принципе. Из плюшек - откат изменений при необходимости делается очень просто. Про единую историю изменений я уже молчу. Если внятно комментировать каждый коммит, то история разработки превращается в открытую книгу. Да что я тут говорю. Расписывать достоинства VCS это даже как-то глупо, даже такой как в 1С. Настолько их много и настолько они очевидны. В 8.3, кстати, сделали возможность фактически мгновенно сравнивать разные версии модулей одного объекта, без построения полных снэпшотов. За что им огромный поклон. Большинство вопросов, что, откуда, когда взялось и кем внесено - решаются очень быстро и удобно.
(44) herfis,
Вот эту возможность и ждал на 8.3. И оооочень был рад релиза. Ну и вообще на 8.3 они хорошо потрудились над конфигуратором. Скорость разработки выросла на порядок.
Мысли в слух: доработать бы шаблоны. Цены разрабам платформы не было бы :)
Настолько их много и настолько они очевидны. В 8.3, кстати, сделали возможность фактически мгновенно сравнивать разные версии модулей одного объекта, без построения полных снэпшотов. За что им огромный поклон. Большинство вопросов, что, откуда, когда взялось и кем внесено - решаются очень быстро и удобно.
Вот эту возможность и ждал на 8.3. И оооочень был рад релиза. Ну и вообще на 8.3 они хорошо потрудились над конфигуратором. Скорость разработки выросла на порядок.
Мысли в слух: доработать бы шаблоны. Цены разрабам платформы не было бы :)
(46) spacecraft, (47) herfis, Я свои шаблоны загрузил на ИС. Правда обновление было в 2014 :( Давно хочу обновить, все руки не доходят.
Ниже несколько наиболее используемых.
Создание подключаемой процедуры. Использую для обновления отборов строк ТЧ, обновлению отборов/параметров ДС.
Вызвается просто: "ПодключитьОбработчикОжидания("Подключаемая_.....", 0.1, Истина);
Вызов процедуры после ответа на вопрос, открытия формы. Сейчас приходится юзать одну на все, и редактировать. Было бы не плохо реализовать какойто вариант выбора группы шаблона.
Тоесть имеем вызов через "Про[цедура]". Выбираем из списка "Описание оповещения". И выбор: Вопрос, ОткрытьФорму и тд. Сейчас приходится выбирать из списка: "Описание - вопрос", "Описание Открыть форму" и тд.
Доработка типовых условий. тут хотелось бы иметь следующую возможность: При вводе условия, через ctrl+space иметь возможность аналогичной конфигуратору. Тоесть продолжать имена переменных.
Аналогично и выше только в двух местах.
Это, в основном, юзаю для проверки в ПриСозданииНаСервере, а передан ли параметр на форму, ибо форма может открываться в многих местах.
Походу "Остапа понесло" :)))))) Звыняйте :)
Ниже несколько наиболее используемых.
Создание подключаемой процедуры. Использую для обновления отборов строк ТЧ, обновлению отборов/параметров ДС.
Вызвается просто: "ПодключитьОбработчикОжидания("Подключаемая_.....", 0.1, Истина);
Процедура (подключаемая) |
|---|
// <?>
//
// Параметры:
// - -
//
&НаКлиенте
Процедура Подключаемый_<?"Название процедуры">() Экспорт
КонецПроцедуры // <?"Название процедуры"> Показать |
Вызов процедуры после ответа на вопрос, открытия формы. Сейчас приходится юзать одну на все, и редактировать. Было бы не плохо реализовать какойто вариант выбора группы шаблона.
Тоесть имеем вызов через "Про[цедура]". Выбираем из списка "Описание оповещения". И выбор: Вопрос, ОткрытьФорму и тд. Сейчас приходится выбирать из списка: "Описание - вопрос", "Описание Открыть форму" и тд.
Процедура описания оповещения |
|---|
// <?>
//
// Параметры:
// Результат - Произвольное - Произвольное значение передаваемое в качестве результата
// ДополнительныеПараметры - Структура - Структура дополнительных параметров
//
&НаКлиенте
Процедура <?"Название процедуры">Завершение(Результат, ДополнительныеПараметры) Экспорт
КонецПроцедуры // <?"Название процедуры">Завершение Показать |
Доработка типовых условий. тут хотелось бы иметь следующую возможность: При вводе условия, через ctrl+space иметь возможность аналогичной конфигуратору. Тоесть продолжать имена переменных.
Если Тогда (типовое мне не нравится :) ) |
|---|
Если <?"Условие"> Тогда
<?>
КонецЕсли; |
Аналогично и выше только в двух местах.
Если ИначеЕсли Тогда (аналогично предыдущему) |
|---|
Если <?"Условие №1"> Тогда
<?>
ИначеЕсли <?"Условие №2"> Тогда
КонецЕсли; Показать |
Это, в основном, юзаю для проверки в ПриСозданииНаСервере, а передан ли параметр на форму, ибо форма может открываться в многих местах.
Если Параметры.Свойство()Тогда |
|---|
<?"Имя параметра"> = Неопределено;
Если Параметры.Свойство("<?"Имя параметра">", <?"Имя параметра">) Тогда
<?>
КонецЕсли; |
Походу "Остапа понесло" :)))))) Звыняйте :)
только что попробовал - внес изменения в обработку, динамически обновился, сложил изменения в хранилище. Платформа 1С:Предприятие 8.3 (8.3.5.1146)
Открыл обработку из хранилища - вижу свои изменения.
Или я не правильно пытаюсь воспроизвести?
Открыл обработку из хранилища - вижу свои изменения.
Или я не правильно пытаюсь воспроизвести?
(5) sommid,
Только что перепроверил, платформа 8.3.7.1845, результат повторился. Думаю ваша ошибка, что вы пытаетесь проверить состояние коммита в той же самой базе. Прикол в том, что хранилище показывает что текущие изменения и версия в хранилище идентичны, сравнение объектов показывает, что они идентичны, но если загрузить изменения в другой базе, то изменений не будет, и хранилище снова будет показывать, что все актуально и версии идентичны.
только что попробовал - внес изменения в обработку, динамически обновился, сложил изменения в хранилище. Платформа 1С:Предприятие 8.3 (8.3.5.1146)
Открыл обработку из хранилища - вижу свои изменения.
Или я не правильно пытаюсь воспроизвести?
Открыл обработку из хранилища - вижу свои изменения.
Или я не правильно пытаюсь воспроизвести?
Только что перепроверил, платформа 8.3.7.1845, результат повторился. Думаю ваша ошибка, что вы пытаетесь проверить состояние коммита в той же самой базе. Прикол в том, что хранилище показывает что текущие изменения и версия в хранилище идентичны, сравнение объектов показывает, что они идентичны, но если загрузить изменения в другой базе, то изменений не будет, и хранилище снова будет показывать, что все актуально и версии идентичны.
shsa, это попытка описать свои ощущения... Код пропадает где и когда?Народ, вы вообще читали что я писал?
1) Захватываете объект
2) Вносите изменения
3) Производите динамическое обновление (важное условие)
4) И только после всего перечисленного делаете коммит
Результат: в хранилище создается новая ревизия, но она содержит старый код до изменения!
Всё! Это легко проверяемая последовательность действий.
Подозреваю, что все кто терял код при использовании хранилища конфигурации, отлаживали свой код на рабочей базе с помощью динамического обновления, получали описанный выше результат, но обнаруживали это спустя какое-то время и не понимали из-за чего все произошло. Поэтому и появились такие сложные рекомендации как чистка кэша и обновление рабочей базы через выгруженный конфиг.
Рекомендация простая: коммитить до динамического обновления.
(8) shsa,
Теперь читаем еще раз:
Прежде чем обновлять другую базу необходимо принудительно "Получить из хранилища". Пробуйте.
Результат: в хранилище создается новая ревизия, но она содержит старый код до изменения!
Прикол в том, что хранилище показывает что текущие изменения и версия в хранилище идентичны, сравнение объектов показывает, что они идентичны, но если загрузить изменения в другой базе, то изменений не будет, и хранилище снова будет показывать, что все актуально и версии идентичны.
Теперь читаем еще раз:
Могу предположить, что новый код не появляется у приятеля, а он также комитет свой код уже без первоначального кода.
Как было сказано, 99% всех проблем с локальным кем хранилища. После захвата хранилища нужно принудительной получить данные из хранилища - это пересоздаст локальный кеш. Тогда и данные теряться не будут
Как было сказано, 99% всех проблем с локальным кем хранилища. После захвата хранилища нужно принудительной получить данные из хранилища - это пересоздаст локальный кеш. Тогда и данные теряться не будут
Прежде чем обновлять другую базу необходимо принудительно "Получить из хранилища". Пробуйте.
(11) spacecraft,
Теперь еще раз читаем:
Разумеется, когда мне впервые пришлось столкнуться с подобной ситуацией, у меня были "идеальные" условия: я только что закоммитили изменения на рабочей базе и пытался получить их на тестовой, и ничего не мог сделать, т.к. их тупо небыло в хранилище. Я в этот период чистил кэш, переподключал хранилище, применял всевозможные попытки вытащить код, пока примитивным анализом ревизий не убедился, что нужного мне кода просто нет в хранилище.
----------
Дополнительно перепроверил предложение с принудительным "Получить из хранилища", на случай, если сам дурак. Система пишет, что такой-то объект получен из хранилища, как и случается всегда при наличии новых изменений, но изменений нет.
Прежде чем обновлять другую базу необходимо принудительно "Получить из хранилища". Пробуйте.
Теперь еще раз читаем:
в хранилище создается новая ревизия, но она содержит старый код до изменения!
Разумеется, когда мне впервые пришлось столкнуться с подобной ситуацией, у меня были "идеальные" условия: я только что закоммитили изменения на рабочей базе и пытался получить их на тестовой, и ничего не мог сделать, т.к. их тупо небыло в хранилище. Я в этот период чистил кэш, переподключал хранилище, применял всевозможные попытки вытащить код, пока примитивным анализом ревизий не убедился, что нужного мне кода просто нет в хранилище.
----------
Дополнительно перепроверил предложение с принудительным "Получить из хранилища", на случай, если сам дурак. Система пишет, что такой-то объект получен из хранилища, как и случается всегда при наличии новых изменений, но изменений нет.
(12) shsa, только что проверил. Делал следующее:
1. Создал новую демо базу.
2. Подключил ее к хранилищу.
3. Создал новую чистую базу.
4. Подключил ее к хранилищу. База конфигурация загрузилась из хранилища.
5. В первой базе создал в обработке процедуру.
6. Запустил отдельно клиента первой базы без принятия изменений.
7. Динамически обновил первую базу.
8. Поместил изменения в хранилище.
9. Во второй базе получил из хранилища.
10. Все изменения отобразились во второй базе.
Что не так?
1. Создал новую демо базу.
2. Подключил ее к хранилищу.
3. Создал новую чистую базу.
4. Подключил ее к хранилищу. База конфигурация загрузилась из хранилища.
5. В первой базе создал в обработке процедуру.
6. Запустил отдельно клиента первой базы без принятия изменений.
7. Динамически обновил первую базу.
8. Поместил изменения в хранилище.
9. Во второй базе получил из хранилища.
10. Все изменения отобразились во второй базе.
Что не так?
(13) spacecraft,
Подтверждаю, что на чистой базе этот фокус не прошел (сделал более 5 круговых обновлений), поэтому соглашусь с утверждением (14) Xershi, что подобная проблема проявляется себя при определенном уровне "засранности" кэша. Что, тем не менее не умаляет ценность моего опыта, т.к. можно говорить о гарантированной потере кода через какое-то время, если коммит делать после динамического обновления, а не до него.
Лично сейчас практикую следующий подход, если приходится работать на живой базе: захватываю объект, отлаживаю его в динамике, когда готов закоммитить, вношу в него незначительное изменение (пробел, комментарий), после этого коммичу.
До того, как столкнулся с этой проблемой, очень долго пользовался хранилищем без единого нарекания, но мой коллега, который регулярно работал с живой базой, довольно часто терял код. Когда мне самому пришлось поработать с живой базой используя динамическое обновление - впервые столкнулся с этой проблемой лично. Описанный мной способ гарантированно повторяется на нашей базе, кэш не чистился очень давно.
P.S.: Почистил сейчас кэш %USERPROFILE%\Local Settings\Application Data\1C\1Cv82\ (%LOCALAPPDATA%\1C\1Cv82\ для ОС Windows Vista и выше) и папку cache репозитория, проверил - проблема повторилась, но с оговоркой: после чистки кэша, появились изменения, которые были потеряны до чистки, но новые изменения все так же "теряются".
Подтверждаю, что на чистой базе этот фокус не прошел (сделал более 5 круговых обновлений), поэтому соглашусь с утверждением (14) Xershi, что подобная проблема проявляется себя при определенном уровне "засранности" кэша. Что, тем не менее не умаляет ценность моего опыта, т.к. можно говорить о гарантированной потере кода через какое-то время, если коммит делать после динамического обновления, а не до него.
Лично сейчас практикую следующий подход, если приходится работать на живой базе: захватываю объект, отлаживаю его в динамике, когда готов закоммитить, вношу в него незначительное изменение (пробел, комментарий), после этого коммичу.
До того, как столкнулся с этой проблемой, очень долго пользовался хранилищем без единого нарекания, но мой коллега, который регулярно работал с живой базой, довольно часто терял код. Когда мне самому пришлось поработать с живой базой используя динамическое обновление - впервые столкнулся с этой проблемой лично. Описанный мной способ гарантированно повторяется на нашей базе, кэш не чистился очень давно.
P.S.: Почистил сейчас кэш %USERPROFILE%\Local Settings\Application Data\1C\1Cv82\ (%LOCALAPPDATA%\1C\1Cv82\ для ОС Windows Vista и выше) и папку cache репозитория, проверил - проблема повторилась, но с оговоркой: после чистки кэша, появились изменения, которые были потеряны до чистки, но новые изменения все так же "теряются".
Было следующее. Повторить не удалось.
1. Захожу в рабочую. Моих изменений нет
2. Я к себе в базу. Нет.
3. У напарника есть.
4. Создаю новую базу в списке. Изменений нет.
5. Чистим кеш хранилища. Изменений нет.
6. Напарник захватил, добавил " ", поместил. Я тяну свои наработки + " ".
Из кешев новое только "кеш ИБ". Видимо нужно еще что-то чистить. Но пока не повторилось :)
1. Захожу в рабочую. Моих изменений нет
2. Я к себе в базу. Нет.
3. У напарника есть.
4. Создаю новую базу в списке. Изменений нет.
5. Чистим кеш хранилища. Изменений нет.
6. Напарник захватил, добавил " ", поместил. Я тяну свои наработки + " ".
Из кешев новое только "кеш ИБ". Видимо нужно еще что-то чистить. Но пока не повторилось :)
(0) Не совсем так. Эта последовательность железно не воспроизводится. Проблема однозначно связана со сбоем локального кеша конфигурации. Сбой происходит, как правило, при динамических обновлениях конфы. И проблемы могут после этого повторяться до тех пор, пока не будет очищен локальный кеш конфигурации (не произойдет полное перекеширование). Поэтому у тебя и воспроизводится, а в нормальных условиях - нет.
Самое прикольное в сбоях локального кэша при работе с хранилищем это то, что если выполняешь сравнение основной конфигурации с конфигурацией хранилища, то оно производится без участия локального кэша. И рапортует мол - все хорошо и одинаково. Открываешь модуль (ессно, закешированный) и смотришь глазками - а нихрена не одинаково.
Очень опасная и практически недиагностируемая хрень. Можно захватить объект, поправить пару строчек и забросить обратно в хранилище версию объекта столетней давности (потому что такая лежала в сбойном кеше). Жуть, короче. Эффективна только профилактика в виде постоянной принудительной очистки кеша или отказ от динамического обновления вообще. В маленьком проценте случаев сбои динамического обновления (нарушение внутренней версионности объектов) вообще способны привести к краху базы. Раза три такое случалось лет за семь. И еще пару раз спасало хранилище в менее брутальных случаях - когда конфигуратор запускался, а запуск предприятия ругался на несоответствие структуры данных базы и конфы. Это лечилось перезаливкой конфы из хранилища (переподключением).
Самое прикольное в сбоях локального кэша при работе с хранилищем это то, что если выполняешь сравнение основной конфигурации с конфигурацией хранилища, то оно производится без участия локального кэша. И рапортует мол - все хорошо и одинаково. Открываешь модуль (ессно, закешированный) и смотришь глазками - а нихрена не одинаково.
Очень опасная и практически недиагностируемая хрень. Можно захватить объект, поправить пару строчек и забросить обратно в хранилище версию объекта столетней давности (потому что такая лежала в сбойном кеше). Жуть, короче. Эффективна только профилактика в виде постоянной принудительной очистки кеша или отказ от динамического обновления вообще. В маленьком проценте случаев сбои динамического обновления (нарушение внутренней версионности объектов) вообще способны привести к краху базы. Раза три такое случалось лет за семь. И еще пару раз спасало хранилище в менее брутальных случаях - когда конфигуратор запускался, а запуск предприятия ругался на несоответствие структуры данных базы и конфы. Это лечилось перезаливкой конфы из хранилища (переподключением).
По поводу сложных схем дистрибуции вспомнился еще вариант с использованием двух хранилищ - для девелоперской ветки и для релизов. Тоже очень имеющий смысл вариант. Но опять таки для более сложного цикла разработки, когда выпуск релизов хоть как-то регламентируется.
Раз уж пошла такая тема, может кто ответит. Вот у вас подключена рабочая база к хранилищу. Если рабочая база на поддержке у поставщика как вы производите обновления? Что будет если обновить свою локальную базу через "Конфигурация-Поддержка-Обновить конфигурацию" и потом в рабочей сделать "Обновить конфигурацию из хранилища"? Корректно отработает или вам приходится стандартное обновление делать только на рабочей базе?
(34) Xershi, расширения не пойдут, изучали пришли к выводу, что вещь хорошая но не для нас.
Про режим редактирования не понял. Вы про настройку правил поддержки "Объект поставщика редактируется с сохранением поддержки"? Если да то не понял как эта настройка поможет обновить конфу на поддержки через хранилище...
А вообще когда мы внедряли хранилище думали привязывать ли рабочую базу к ней или нет. Если я правильно помню то одним из аргументов против было то, что нигде никто не говорит как обновлять потом конфу на поддержке. Всё ли будет корректно если обновить сначала в хранилище, а только потом из него получить в рабочую?
У кого-нибудь есть опыт по данному вопросу?
Про режим редактирования не понял. Вы про настройку правил поддержки "Объект поставщика редактируется с сохранением поддержки"? Если да то не понял как эта настройка поможет обновить конфу на поддержки через хранилище...
А вообще когда мы внедряли хранилище думали привязывать ли рабочую базу к ней или нет. Если я правильно помню то одним из аргументов против было то, что нигде никто не говорит как обновлять потом конфу на поддержке. Всё ли будет корректно если обновить сначала в хранилище, а только потом из него получить в рабочую?
У кого-нибудь есть опыт по данному вопросу?
(35) klinval, речь идет не о доработках, а об типовом обновлении? Попробуйте на тестовой базе развернуть демо-базу. На нее повесить хранилище. Затем отпочковать базу для разработки. Захватить все объекты. Предварительно поставить конфу на редактирование. И обновите типовым методом обновления базу для разработки. Потом залейте все в хранилище и в рабочей все получите.
(36) Xershi, хотелось бы получить отзывы тех кто делал так на боевой базе и не раз. Мы подобные примеры делали, но не на боевой. Вроде запускалась база, вроде с конфой поставщика всё ОК, вроде первый запуск - шло обновление... Но я не видел ни одной записи о том что кто-то так делает на постоянной основе. Не хочется быть первопроходцами и собирать все шишки. В 1С по этому поводу описания тоже не нашёл!
Просто подумал раз на форуме тут многие подключают хранилище к рабочей базе может хоть у кого-то рабочая база на поддержке поставщика? Похоже что у всех сплошь свои базы... Понятно тогда почему вы подключаете к хранилищу, я бы может тоже подключил если бы база была не на поддержке.
Просто подумал раз на форуме тут многие подключают хранилище к рабочей базе может хоть у кого-то рабочая база на поддержке поставщика? Похоже что у всех сплошь свои базы... Понятно тогда почему вы подключаете к хранилищу, я бы может тоже подключил если бы база была не на поддержке.
(43) Xershi,
Поверьте - нужно! Если вы ни разу серьезно не редактировали типовую базу - я вам завидую. Т.к. это совершенно другое программирование. Тут, например нужно соблюдать баланс между тем как надо грамотно сделать (с точки зрения правильного кодирования, а не в плане результата) и как сделать минимально изменив типовой механизм чтобы учитывать как это всё легко/сложно будет обновлять... А обновление это вообще отдельная песня со своими нюансами.
Вот вам банальный пример: помните на ИС была отдельный блок выделен по вопросу "НДС 2015". Почему думаете столько платных разработок было и такой интерес со стороны ИС? Это потому что 1С в типовых решениях отказалось от возможности ручного редактирования новых разделов декларации, да и авто-заполнение оставляло желать лучшего. Причём техподдержка можно сказать нас послала. Т.е. с их точки зрения - всё ОК, а почему есть куча платных решений проблемы которой нет - они вообще не понимают до сих пор!:) А общение с ТП по ошибкам в типовых решениях 1С - это тоже отдельная история...
Внешние обработки и отчеты, а теперь ещё и расширения, помогают только тогда когда изменений мало.
Я бы мог подробнее описать и разъяснить каждую фразу своего сообщения, только займёт это кучу времени, да и тема не об этом. Если интересно - пишите в личку вопросы, постараюсь ответить.
А с типовыми да еще и на полной поддержке какие доработки? Внешние обработки да отчеты?
Поверьте - нужно! Если вы ни разу серьезно не редактировали типовую базу - я вам завидую. Т.к. это совершенно другое программирование. Тут, например нужно соблюдать баланс между тем как надо грамотно сделать (с точки зрения правильного кодирования, а не в плане результата) и как сделать минимально изменив типовой механизм чтобы учитывать как это всё легко/сложно будет обновлять... А обновление это вообще отдельная песня со своими нюансами.
Вот вам банальный пример: помните на ИС была отдельный блок выделен по вопросу "НДС 2015". Почему думаете столько платных разработок было и такой интерес со стороны ИС? Это потому что 1С в типовых решениях отказалось от возможности ручного редактирования новых разделов декларации, да и авто-заполнение оставляло желать лучшего. Причём техподдержка можно сказать нас послала. Т.е. с их точки зрения - всё ОК, а почему есть куча платных решений проблемы которой нет - они вообще не понимают до сих пор!:) А общение с ТП по ошибкам в типовых решениях 1С - это тоже отдельная история...
Внешние обработки и отчеты, а теперь ещё и расширения, помогают только тогда когда изменений мало.
Я бы мог подробнее описать и разъяснить каждую фразу своего сообщения, только займёт это кучу времени, да и тема не об этом. Если интересно - пишите в личку вопросы, постараюсь ответить.
Мысли в слух: доработать бы шаблоны. Цены разрабам платформы не было бы :)
В смысле, стандартные? Или сам механизм? Стандартные дорабатывались, кстати. Многие варианты от Groovy стали неактуальны.
Но у меня как-то не сложилось с шаблонами. Хотя пробовал неоднократно. И от Groovy и свои составлял на их базе...
Как-то не прижились. Слепым десятипальцевым и автодополнением когда надо по Ctrl+Space привычнее как-то и особо не медленнее выходит.
Пытался сделать так, чтобы по Ctrl+Space можно было и шаблоны выбирать - но там засада с этим сейчас. Однотипные шаблоны выскакивают с одинаковыми названиями в автодополнении и это жутко неудобно. Так что вообще нафиг отключил их.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот