search

Acosix / alfresco-simple-content-stores

Addon to provide a set of common content store implementations and easy-to-use configuration (no Spring config)
Apache License 2.0
43 stars 19 forks source link

Moving content between stores and versioning #26

Closed lmeunier closed 4 years ago

lmeunier commented 4 years ago

Hello,

Module version: master Alfresco version: 5.2.6 Enterprise

Configuration:

simpleContentStores.enabled=true
simpleContentStores.customStores=test1Store,test2Store,testRoutingStore,defaultTenantFileContentStore
simpleContentStores.rootStore=testRoutingStore

simpleContentStores.customStore.testRoutingStore.type=selectorPropertyRoutingStore
simpleContentStores.customStore.testRoutingStore.ref.fallbackStore=defaultTenantFileContentStore
simpleContentStores.customStore.testRoutingStore.value.selectorClassName=my:aspect
simpleContentStores.customStore.testRoutingStore.value.selectorPropertyName=my:property
simpleContentStores.customStore.testRoutingStore.map.storeBySelectorPropertyValue.ref.valueTest1Store=test1Store
simpleContentStores.customStore.testRoutingStore.map.storeBySelectorPropertyValue.ref.valueTest2Store=test2Store
simpleContentStores.customStore.testRoutingStore.value.moveStoresOnChange=true

simpleContentStores.customStore.test1Store.type=standardFileStore
simpleContentStores.customStore.test1Store.value.protocol=test1
simpleContentStores.customStore.test1Store.value.rootAbsolutePath=/data/alf_data/test1Store

simpleContentStores.customStore.test2Store.type=standardFileStore
simpleContentStores.customStore.test2Store.value.protocol=test2
simpleContentStores.customStore.test2Store.value.rootAbsolutePath=/data/alf_data/test2Store

When the property my:property is changed the content is copied to the new store. Now the node have 2 versions:

The old content in store://... will not be cleaned as it is not orphaned. Is this the expected behavior? When setting moveStoresOnChange=true I expect that content is copied to the new store and old content is orphaned.

I did more tests with version.store.enableAutoVersioning=false (as described here https://docs.alfresco.com/5.2/tasks/autoversion-disable.html, no new version should be created even if the node has the versioning aspect).

Even with this, a new version is still created when my:property is changed.

To change my property value, I use the following javascript code:

var n = search.findNode("workspace://SpacesStore/b37a7deb-3aad-4a65-a657-93d901f6f056");
n.addAspect("my:aspect");
n.properties["my:property"] = "valueTest1Store";
n.save();

I don't understand why a new version is always created. Any thoughts on this?

Laurent

AFaust commented 4 years ago

The property version.store.enableAutoVersioning=false only controls the default behaviour of the versionable aspect unless a client provides custom overrides. The Share client e.g. always provides such overrides when applying the versionable aspect when uploading a document - so the setting really does not take effect unless you exclusively use different interfaces, like WebDAV / CMIS where versioning is not enabled by default by the client. That being said - the default behaviour that Share specifies should never version on just a simple property change. Unless some other customisation / extension is installed in Alfresco which messes with versioning (simple-content-stores does not), you should not see any versions created on trivial property changes.

With regards to the content copy / move: I am glad to see you have already applied the different protocols - quite a few people overlook this requirement in making this work correctly. Now after a copy / move, any content will only be considered orphaned if it is not referenced by a live node either in the main, version or archive spaces. Since your old version references the old content in the defaultTenantFileStore it cannot be cleaned up, as the file must be kept in case the version is restored / document reverted to that state. The old version would have to be deleted for the file to become orphaned and clearable.

So far, this is indeed the expected behaviour. As versions are supposed to be immutable (and there are technical guards in place by Alfresco to ensure they are), the simple-content-stores does not meddle with their state. Technically, it would be possible to circumvent the protective guards of Alfresco, but it would be extremely "dirty", and might break compliance / traceability requirements for other users of the addon, where the integrity of versions must be maintained. Potentially, the addon could provide an optional mode / option property on nodes to specify wether versioned nodes should also have their content copied / moved - albeit with some big, yellow/red warning signs in the documentation for admins / devs.

lmeunier commented 4 years ago

Many thanks for all these valuable informations.

I've checked, we do not have other customisation / extension installed in Alfresco which messes with versioning. From what I've seen, a new version is created only when my:property is changed. No new version for other properties. And if I change the module configuration to use my:other_property as selectorPropertyName, a change to my:property does not create a new version, but a change to my:other_property does. It seems that as soon the cm:content property is changed (when triggered by a change to the property defined by selectorPropertyName) a new version is created.

At least this is the behavior I observe when testing with Share. With CMIS, no new version are created when my:property is changed. Except that, as soon as the cm:versionable aspect is applied, a version is created in workspace://version2Store. So, I need to set my:propery before applying the cm:versionable aspect.