Как лучше всего архивировать документы в репозитории Jackrabbit?

Требование:
у меня есть требование, в котором мне нужно заархивировать некоторые из nt:file узлов в репозитории, которые можно будет восстановить на более позднем этапе. Эти узлы nt:file после архивирования не должны быть видны при поиске в репозитории. Но после восстановления они должны стать доступными для поиска.

Подход:

Переместите папки, которые нужно заархивировать, в папку, например, Temp, в ту же папку workspace. И как только пользователь попытается восстановить узел, его следует вернуть туда, где он существовал. Это кажется правильным подходом?

  • Если кто-то уже реализовал такой функционал, то можно поделиться опытом и подходами, или
  • Каковы возможные варианты реализации такой функциональности?

java jackrabbit jcr content-repository
person Aman Arora    schedule 07.10.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Перемещение этих узлов в определенную папку /archive звучит хорошо для меня.

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

Чтобы пользователи могли разархивировать документы, вы можете оставить «теневой» узел при переходе к архиву с достаточной информацией, чтобы авторизованные пользователи могли разархивировать документы.

person Bertrand Delacretaz    schedule 07.10.2014
comment
Спасибо за ответ @Bertrand. У меня есть одна проблема с этим подходом. После того, как узел был заархивирован, если пользователь попытается снова добавить тот же узел, он будет сохранен. И тогда, если заархивированный узел будет восстановлен, это приведет к ItemExistsException. Есть ли способ, этого можно избежать? - person Aman Arora; 08.10.2014
comment
Это еще одна причина оставить теневой узел — если вы переместите, скажем, /content/foo в /archive/foo, оставьте узел в /content/foo, который указывает на заархивированный узел, и настройте контроль доступа к этому узлу, чтобы пользователи не могли изменять /content/foo и, возможно, даже не видит его. - person Bertrand Delacretaz; 09.10.2014
comment
Я могу придумать еще один вариант, т.е. создать mixinNode с логическим свойством isDeleted. И присоединение mixinNode к файловому узлу, когда он удаляется. При поиске я исключаю все узлы nt:file со свойством isDeleted, равным true Вы видите какие-либо проблемы в этом подходе? - person Aman Arora; 09.10.2014
comment
Это, безусловно, сработает, возможно, потребуется больше работы на уровне приложения, но это зависит от того, как структурировано ваше приложение. - person Bertrand Delacretaz; 09.10.2014