实现自定义的存储类型并且具有不发布问题


5

我有一个自定义的存储扩展我构建的问题。基本上,我的任务是删除对文件系统/持久性存储类型的依赖。我们将发布到Couchbase,而不是文件系统或代理数据库。

我已经通过编写一个抽象类来完成这项工作,它扩展了com.tridion.storage.dao.AbstractBaseDAO。然后,我的DAO类扩展了这个类,而不是类似com.tridion.storage.filesystem.FSPageDAO

我设法让它发布到Couchbase,但即使返回成功状态,un-publishing也不会发生。我在我的CouchbasePageDAO类中甚至没有从我的remove方法中获取任何日志记录。

cd_storage_conf.xml文件的最低版本是这样的:

<?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> 

null存储类型的只是实现了所有项目类型,并注销被称为方法时。如果我将defaultStorageId更改为defaultFile,则取消发布将按预期工作。

我只能认为,有相当缺失,需要实施某些项目类型一点的功能。正如我以前从未见过任何人这样做,或任何在线的例子,我不知道如何进步。

看起来很奇怪,我没有发布问题,当我使用我的空存储类型作为默认类型。也许有一些参考检查需要执行?我从com.tridion.storage.dao.ReferenceEntryDAO实施了一个项目类型,但不确定我在找什么,或者如果这是一条红鲱鱼。

四处阅读,我怀疑没有人真的走上这条路,但如果有人有任何这方面的经验/知识,我会很感激。

  0

为什么你有和“空”存储类型和couchbase一个?你重写DAO的配置,以及,如下解释:https://community.sdl.com/solutions/content-management/tridion/tridion-developer/b/weblog/posts/howto-extending-content-broker-storage ?另外 - 我认为你的工厂需要在Spring的com.tridion.storage命名空间下才能找到它们。而且 - 有像“零”的名称实际上可能导致问题:O) 08 5月. 172017-05-08 14:25:56

  0

我同意空的名字,并一直打算重新命名这些类。对于未指定的项目类型,空类型是默认存储类型。在我的示例中,我只显示了页面项类型,但我还实现了Couchbase存储类型中的ComponentPresentation,Binary,Taxonomy和Metadata。任何其他类型将默认为空存储类型。它们都是实现的,但是当它调用方法时,每个空项类型都会注销。我不需要使用存储包xml配置进行配置,因为它们目前在工厂类中是硬编码的。 08 5月. 172017-05-08 15:02:12

  0

我会看一下名称空间,因为我已经看到过之前提到过的名称空间。就像我所说的出版作品一样,内容仍然坚持到Couchbase,即使它宣称成功,也无法取消发布。 08 5月. 172017-05-08 15:02:26

  0

您的后一条评论可能确实表明DAO未装载或工厂与您打算的不同。然而,我看到其中取消部署代码需要PageMeta为存在:如果(!pageMeta = NULL){// 除去代码 } ..所以我认为你需要为它嘲笑一些东西? 08 5月. 172017-05-08 15:10:37

  0

你确实提到你正在扩展com.tridion.storage.filesystem.FSPageDAO。你是否也实现了com.tridion.storage.dao.PageDAO? 08 5月. 172017-05-08 16:27:22

  0

不,我没有扩展FSPageDAO,因为我不想使用任何文件系统存储代码功能。我创建了自己的CouchbaseBaseDAO抽象类,它扩展了AbstractBaseDAO。我怀疑这是我取消发布困境的原因。 FSPageDAO在取消部署时可能会做的事情,我没有实现。 08 5月. 172017-05-08 17:02:49

  0

我认为如果你编辑你的问题并提供一些你正在使用的代码(基准代码,不是完整的实现)的更多细节,这是有意义的。当检查文件(http://docs.sdl.com/LiveContent/content/en-US/SDL%20Tridion%20full%20documentation-v1/GUID-EE4379AB-CF9F-4D2C-9F66-FDD522C7E0C6),它提到实施你自己的存储类型,你应该有它落实'DAOFactory',而不是扩展'AbstractBaseDAO' 09 5月. 172017-05-09 06:43:34

+1

我认为你需要确保pageMeta存在,它会对你有帮助。 :) 09 5月. 172017-05-09 08:34:07

  0

雷蒙,你是正确的,返回一个'PageMeta'对象以最小的属性(文件名/ URL/templateid)触发取消部署。 11 5月. 172017-05-11 12:12:11

2

Tridion Deployer中的undeploy机制不仅需要Page存在,还需要关联的PageMeta对象。

如果您执行自定义DAO实现,则必须确保通过存储层中的PageMeta对象捕获某些最小形式的页面元数据,以便触发取消部署。