Plone 轻量级灵巧基础内容类型可以是什么

我正在尝试写一个轻量级的内容类型，类似于Facebook的帖子

• 整个内容架构只是一个文本字段。没有标题，没有描述

• 它必须是Contentish，由CMFCore管理：它必须有一个FTI，一个portaltype，以便我们可以通过标准方法创建/浏览内容；它是目录感知的

• 他们之间会有联系/参考

• 物体的数量将是巨大的，比如说10-100米

与此最相似的是comment对象（plone.app.discussion）。虽然我浏览了plone.app.discussion，但我发现内容实现非常复杂，有太多低级基类。在大多数情况下，我要么根本不理解它，要么它不能在注释用例之外重用，对我来说几乎没有参考/示例价值

---

所以我想问的是，与plone.app.discussion所经历的低级框架相比，如果我采用高级框架路径，会有多少开销

我认为p.a.讨论不适合你

灵巧型可能不错，但需要调整性能。如果性能将成为一个问题，那将是因为使类型成为contentish（例如FTI、CMF基类）的因素，因此没有什么比灵活性更轻，可以满足您的要求，但您可能需要考虑是否确实要将所有内容存储在关系数据库中或其他内容中。不过，这不应该是绝对必要的

---

Martin

Plone不会在其目录中扩展到1000万个项目（我所听说的最大的项目大约有40万个）。我建议您使用类似金字塔的轻量级框架构建应用程序。

您认为问题出在哪里？ZODB不能大规模扩展吗？目录太大，无法装入客户端内存？目录的实现很差，以至于超过百万个对象的查询占用了太多的cpu？这里的问题不是ZODB。问题在于，Plone的portal_目录在每次写入数据库时都会成为单一的争用点。不幸的是，Plone的所有导航都是基于目录构建的，这使得异步目录更新很难实现。这需要修复，但这是一个长期项目。