Documentum DFS: работа с символическими метками без вмешательства в системные метки
Я работаю с EMC Documentum 6.6, используя DFS Java API. В настоящее время я ищу способ добавлять и обновлять символические метки в документах, не мешая системным меткам.
Насколько я понимаю, все метки (системные метки и символические метки) просто хранятся в повторяющемся атрибуте документов r_version_label. Это означает, что когда я создаю новый документ без установки атрибута r_version_label, сервер автоматически устанавливает системные значения по умолчанию 1,0 и CURRENT.
Но как только я хочу назначить символическую метку исходной версии документа, я также должен позаботиться о настройке 1,0 и CURRENT, потому что сервер не установит их автоматически. Documents without the system labels are kind of broken, they can only be found via Webtop when searching for hidden objects and can also cause client-side errors when viewing their properties.
Another related problem might arise when building an interface for updating document attributes: The client-side developer would have to care of preventing users from modifying system labels and only let them add or remove symbolic labels.
I do understand that this behaviour can also be useful - for example, it would be possible to create a document starting with version 3.0, for whatever reason.
In my case, however, it would be easier to have the possibility to only work with the symbolic labels and leave management of the system labels completely to the server. Я что-то пропустил?
EDIT: Seems like there is no other option than manually taking care of adding the required initial system-labels. I'll accept Chris' answer since he reconfirmed that.
1 ответ
Служба версий предоставляет помощь для следующей незначительной / основной нумерации, но вы всегда должны явно указывать метку версии CURRENT, иначе она будет отсутствовать.
versionService.checkout( toVersionIds, options );
DataPackage versioned = versionService.checkin( toVersion, VersionStrategy.NEXT_MINOR, false, Arrays.asList( new String[]{"CURRENT"} ), options );
Это будет реализовывать 1.0 -> 1.1 или с VersionStrategy.NEXT_MAJOR 1.0 -> 2.0