4

I am having an issue with a custom storage extension I am constructing. Essentially I have been tasked to remove any dependency on filesystem/persistence storage types. We are publishing to Couchbase, and not the filesystem, or broker database.

I've done this by writing an abstract class that extends com.tridion.storage.dao.AbstractBaseDAO. My DAO classes then extend this class rather than something like com.tridion.storage.filesystem.FSPageDAO.

I've managed to get it to publish to Couchbase, but un-publishing never occurs, even though the success state is returned. I don't even get any logging from my remove method in my CouchbasePageDAO class.

A minimal version of my cd_storage_conf.xml file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration Version="7.0">
    <Global>
        ...
        <Storages>
            <Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="defaultFile" defaultFilesystem="false">
                <Root Path="C:\tridion\data" />
            </Storage>
            <Storage Type="null" Class="com.customer.tridion.storage.NullDAOFactory" Id="null" />
            <Storage Type="couchbase" Class="com.customer.tridion.storage.couchbase.CouchbaseDAOFactory" Id="couchbase"></Storage>
        </Storages>
    </Global>
    <ItemTypes defaultStorageId="null" cached="false">
        <Item typeMapping="Page" cached="true" storageId="couchbase" />
    </ItemTypes>
</Configuration>

The null storage type just implements all item types, and logs out when methods are called. If I change the defaultStorageId to defaultFile, un-publishing works as expected.

I can only think that there is quite a bit of functionality missing for certain item types that needs implementing. As I've never seen anyone do this before, or any examples online, I've no idea how to progress.

Just seems odd that I don't have a problem publishing, when I use my null storage type as the default type. Maybe there are some reference checking that needs to be performed? I've implemented an item type from com.tridion.storage.dao.ReferenceEntryDAO, but not really sure what I'm looking for, or if is this is a red herring.

Reading around, I suspect no one really goes down this route, but if anyone has any experience/knowledge of this, I'd appreciated it.

  • Why do you have and a 'null' Storage Type and a couchbase one? Did you override the DAO configuration as well, as explained here: community.sdl.com/solutions/content-management/tridion/…? Additionally - I think your factories need to be under the com.tridion.storage namespace for Spring to pick them up. Further - having a name like 'null' may actually cause issues :o) – Raimond May 8 '17 at 14:25
  • I agree on the null name, and always intended to rename those classes. The null type is the default storage type, for item types that aren't specified. In my example I've only shown the page item type, but I've also implemented ComponentPresentation, Binary, Taxonomy, and Metadata in the Couchbase storage type. Any other types will default to the null storage type. They are all implemented, but all each null item type does is log out when it's methods are called. I didn't need to configure using a storage bundle xml config, as these are currently hard coded in the factory class. – Andy Rowland May 8 '17 at 15:02
  • I'll have a look at the name spaces, as I've seen this mentioned before. Like I say publishing works, and content is persisted to Couchbase, just not able to un-publish even though it states success. – Andy Rowland May 8 '17 at 15:02
  • Your latter comment might indeed indicate that either a DAO isnt loaded or the factory is a different one than you intend. However, I see that the code which undeploys needs PageMeta to be present: if (pageMeta != null) { // remove code } .. So I think you need to maybe mock something for it? – Raimond May 8 '17 at 15:10
  • 1
    I think you need to ensure that pageMeta is present and that it will work then. :) – Raimond May 9 '17 at 8:34
2

The undeploy mechanism in the Tridion Deployer requires not only the Page to be present but also the associated PageMeta object.

If you do a custom DAO implementation, you have to ensure that some minimal form of page metadata captured though a PageMeta object is present in your storage layer for the undeploy to be triggered.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.