На Infostart и других ресурсах есть много публикаций связанных с восстановлением «битых ссылок», но все они одного типа, они позволяют «Исправить» свершившийся факт удаления и действуют по принципу:
- Восстанавливают объект, записав в Наименование, например «Восстановлен <Объект не найден> (54:82d5d897ba0899c911e8ca70137f2d25)». А когда-то возможно этот объект был "Докторская колбаса ГОСТ". При этом все реквизиты восстанавливаются путем ручного ввода.
- Подымается база данных и к ней цепляются (Com, OData и т.д.) и ищут объект по восстановленному GUID объекта. То есть, чтобы восстановить элемент справочника, нужна копия базы.
- Есть и другие методы. Разница в основном лишь в поиске битых ссылок.
Я НЕ ПРЕДЛАГАЮ еще одну обработку по поиску и восстановлению битых ссылок, Я ПРЕДЛАГАЮ использовать слова Александра Македонского: — «Лучшая защита — нападение».
Судите сами, в БСП есть подсистема «Версионирование объектов», в которой уже есть функционал "Создания версии объекта" и "Восстановления версии объекта". Остается только взять этот функционал, доработать и создать версию объекта «ПередУдалением», ну и добавить возможность восстановить объект по сохраненной версии.
За основу взяты механизмы из "Библиотеки стандартных подсистем", (3.0.1.279). Работает на конфигурациях с БСП и без БСП.
Текущий функционал:
- Сохранение и хранение версий по выбранным Документам и Справочникам в виде Fast InfoSet (ЧтениеЗапись реализована в версии 8.3.10.2168.). Подписка на событие ПередУдалением
- Восстановление Документов и Справочников по битой ссылке. (Спасибо автору статьи Битые ссылки за его способ определения типов битой ссылки)
- Восстановление Документов и Справочников по GUID и типу.
Тестировалась система на следующих конфигурациях и платформе:
- 1С:Предприятие 8.3 (8.3.12.1685)
- Не типовые конфигурации (Без БСП)
- Демонстрационное приложение (1.0.26.4)
- Демо "Библиотека стандартных подсистем", (3.0.1.279)
- Демо Управление торговлей, редакция 11 (11.4.5.111)
По ходу тестирования на других платформах и конфигурациях список буду обновлять.
Установка кратко:
Установка подробно:
После установки:
Примеры:
Пример использования на базе с БСП:
Пример использования на базе без БСП:
Будущее и помощь:
- Механизм по поиску битых ссылок. Пока решаю писать свой или использовать чей-то готовый, но какую обработку взять? Подскажите в комментариях на какую обратить внимание. Или может быть вы автор одной из таких обработок, и хотите поучаствовать в данной нестандартной подсистеме.
- Создать единую базу по сбору версий. Обмен по средствам HTTP-Сервисов.
- Обмен версиями с подсистемой "Версионирование объектов".
Релизы:
Версия 0.0.5 (Текущая)
Почему живая вода? Я бы назвал это корзиной.
Сработает ли если битая ссылка возникла во время обмена риб?
(2) автор же написал перед удалением. А после обменов и не только РИБ объектов ещё не было, там сразу битая ссылка.
Удаление не реализовано, потому что в РС.ВерсииОбъектов сам Объект сделан как Ссылка. Это очень плохо по многим причинам.
Например в аналогичной самописной я свободно использую логирование удаления, восстановление.
Использую только простые типы и как следствие свободное перемещение истории во внешнюю базу с доступом по внешнему источнику. А там полное раздолье: секционирование, сжатие, хоть за 100 лет история.
Полный комфорт.
Вместо одной корзины здесь 2 корзины. Достаточно сложное решение. Аналогичный эффект можно получить просто скрывая помеченные на удаление элементы из формы списков.
(1)Корзина вызывает у меня какие то негативные ощущения, да и это Микрософтская тема.
Живая вода — элемент сказок. Убили, полили, оживили.
Вообще по подписке на событие версия записывается в РС и поидее если передать данные РС тогда сработает.
П.С. В следующих версиях планируется отдельное Хранилище для версий созданных перед удалением. Ну и механизм обмена по http нарисую.
(5) 2-е корзины? Не совсем понял где вторая?
Эффект от скрывания помеченных на удаление не аналогичный…
В планах создать отдельную базу в которую будут стекать версии. То есть ошметки будут храниться в отдельном хранилище, а помеченные это тот шлак который никуда не делся.
(4)Я планирую тоже внешнюю базу в следующем релизе с коннектом по http, но через ВИП тоже вариант.
(8) а в какой среде собираетесь хранить данные и поднимать http?
Через внешний источник данные получаются мгновенно. Это очень удобно. Запросы, динамические списки и т.п.
HTTP — вещь перспективная, но архитектурно более сложная реализация.
(9) Мудрить не буду. На 1с сделаю.
Там по идее работы часа на два, просто пока с временем не получается.
(10) вот это и хотел спросить. Это плохой вариант.
Лишняя база 1с. Бррррр… Лишняя прослойка. Зачем?
Я думал что вы замахнулись на какой-нибудь OneClick )))
У меня реализация такая:
— пишется с текущую базу
— регламентно джоб скуля переносит данные во внешнюю базу, но на этом же сервере (можно рассматривать другой)
— читаем только через внешний источник…
Работоспособность никак не зависит от коннекта ,наличия базы и т.д. На миллиардах записей все крайне производительно.
(11) Пока так, а потом посмотрим и в других направлениях в будущем.
У меня просто накопилось куча идей которые хочется наконец то просто реализовать. Время внезапно появилось, на больничном сейчас на долгом сижу с июля до конца года. Вот в этом году статьи и клипаю ;))
А уже потом когда реализую и изложу то что хотел, можно заморачиваться.
1) помечаем элемент на удаление, он попадает в первую корзину.
2) удаляем элемент непосредственно, при этом согласно вашему алгоритму создается и хранится его версия. Это и есть вторая корзина с версиями удаленных элементов.
Корзина — подмножество элементов БД.
Зачем что то удалять, а потом создавать версии, если можно просто не удалять, а скрывать из поля зрения.
(13)Все, я Вас понял.
Кому то нужно хранить все и за все время, а кому то нет.
Удалять или нет, тут вопрос и к объему БД и к виду деятельности и к профессионализму пользователей (бывают ошибки, дубли и т.д. Много, что бывает).
Не зря же есть сроки хранения данных(дел), документооборот, ГОСТы по делопроизводству, документоведы и процедуры уничтожения старыхархивных дел.