基于敏捷的内容类型的轻量级如何
我正在尝试编写一种类似于 Facebook 帖子的轻量级内容类型。
整个内容架构只是一个文本字段。没有标题，没有说明。
它必须是Contentish并且由CMFCore管理：它必须有一个FTI，一个portaltype，以便我们可以通过标准方法创建/浏览内容；它是目录感知的。
他们将在彼此之间建立关系/参考。
对象的数量将会很大，比如 10-100M。
与此最相似的是评论对象（plone.app.discussion）。当我查看 plone.app.discussion 时，我发现内容实现非常复杂，有太多低级基类。在大多数部分中，我要么根本不理解它，要么无法在评论用例之外重用，并且对我来说几乎没有参考/样本价值。
所以我想问的是，如果我采用高级框架路径与 plone.app.discussion 经历的低级框架路径相比，会有多少开销？
I'm trying to write a light weight content type that work similar to Facebook's post.
The whole content schema is just a text field. There's no title, description.
It must be Contentish and is managed by CMFCore: It must have an FTI, a portaltype so that we can create/browse content through standard method; it is catalog-aware.
They will have relation/reference within each others.
The number of objects is gonna be huge, say 10-100M.
The most similar things to this is the comment object (plone.app.discussion). While I've looked through the plone.app.discussion, I found the content implementation is really complicated, with too much low level base classes. In most of the parts, I either don't understand it at all or it can't be reused outside the comment use case, and have little referenced/sample value to me.
So I want to ask is how much overhead it will be if I go the high level framework path compare to the low level one that plone.app.discussion went through ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为帕迪讨论不适合你。
敏捷类型可能没问题，但您需要调整性能。如果性能将成为一个问题，那将是因为使类型变得内容丰富的因素（例如 FTI、CMF 基类），因此没有什么比 Dexterity 更轻并且可以满足您的要求，但您可能需要考虑关于您是否真的想将所有内容存储在关系数据库中还是其他数据库中。不过，这并不是绝对必要的。
马丁
I don't think p.a.discussion is right for you.
A Dexterity type may be fine, but you'll need to tune the performance. If performance is going to be an issue, it'll be because of the things that make types contentish (e.g. an FTI, the CMF base classes), so nothing will be lighter than Dexterity and meet your requirements, but you may want to think about whether you actually want to store everything in a relational database or something else instead. It shouldn't be strictly necessary, though.
Martin
Plone 不会扩展到其目录中的 10 M 项（我听说过的最大项约为 400 k）。我建议使用 Pyramid 等轻量级框架构建您的应用程序。
Plone will not scale to 10 M items in its catalogue (the largest I've heard of is something like 400 k). I would suggest building your application with a light weight framework like Pyramid.