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.

Improve this question
9
  • 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
    Commented May 8, 2017 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
    Commented May 8, 2017 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
    Commented May 8, 2017 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
    Commented May 8, 2017 at 15:10
  • 1
    I think you need to ensure that pageMeta is present and that it will work then. :)
    – Raimond
    Commented May 9, 2017 at 8:34

1 Answer 1

Reset to default
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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