Performance plone.scale注释用(无用的?)比例膨胀

Performance plone.scale注释用(无用的?)比例膨胀,performance,plone,zodb,Performance,Plone,Zodb,在调查冲突错误时(),我看到了很多persistent.mapping.PersistentMapping冲突 查看一个特定的映射,结果是plone.scale的持久映射 结果表明,只有一个图像的随机对象上有562个键,难怪会出现冲突错误 保存此plone.scale注释的对象上的某些上下文: -灵巧内容类型 -其行为之一具有图像字段(plone.namedfile.field.NamedBlobImage) 查看它的代码如下所示: 启动调试实例:/bin/instance debug from

在调查
冲突错误时
(),我看到了很多
persistent.mapping.PersistentMapping
冲突

查看一个特定的映射,结果是
plone.scale
的持久映射

结果表明,只有一个图像的随机对象上有562个键,难怪会出现冲突错误

保存此
plone.scale
注释的对象上的某些上下文: -灵巧内容类型 -其行为之一具有图像字段(
plone.namedfile.field.NamedBlobImage

查看它的代码如下所示:

启动调试实例:
/bin/instance debug

from ZODB.utils import p64
OID = 0x568428  # got from zeo client logs
mapping = app._p_jar[p64(OID)]
len(mapping)  # that returns 562
神秘的是,持久映射上只有4个键是元组,而其他558个键只是散列

简单地看一下这个方法似乎意味着在持久映射上元组和散列键之间应该只有一对一的关系

进一步研究这些元素会发现,实际上,如果您查看所有元素的
width
height
属性,只有4种不同的组合(元组本身的组合)

当修改的时间变大时(参见上面提到的scale方法)会生成一个新的比例,并使用上下文作为修改的源,这意味着每次更新对象时都会生成一个新的比例

因此,前一个问题产生了两个问题:

  • 我的假设是,只有4个量表被真正使用,而另外558个量表是旧的、无用的,这是真的吗

  • 如果上一次的回答是肯定的,那么他们不应该被清理吗


你可能是对的,但报告这一点的正确地点肯定是

是的,但首先在这里询问你是否遗漏了一些明显的内容是一个好主意。我有时间准备测试和补丁(实际上只有一行):