我有数十万个基于 plone 原型(plone 2.5.X)的对象,它们需要将其原型模式更新到最新版本。原型模式迁移工具非常适合中小数量的对象,但它让我的服务器陷入困境,试图迁移它们,以至于我总是最终杀死脚本。我希望能够一次更新一个对象的架构,可能作为检索到的对象 - 这可能吗?如果没有,还有其他方法可以在大型克隆站点中更新原型模式吗?
提前致谢!
我有数十万个基于 plone 原型(plone 2.5.X)的对象,它们需要将其原型模式更新到最新版本。原型模式迁移工具非常适合中小数量的对象,但它让我的服务器陷入困境,试图迁移它们,以至于我总是最终杀死脚本。我希望能够一次更新一个对象的架构,可能作为检索到的对象 - 这可能吗?如果没有,还有其他方法可以在大型克隆站点中更新原型模式吗?
提前致谢!
在挖掘了 2.5 目录代码之后,我终于找到了懒惰模式更新的答案:
if not self._isSchemaCurrent():
logging.debug("updating schema for %s"%self.absolute_url())
try:
import transaction
transaction.begin()
self._updateSchema()
transaction.commit()
except Exception, e:
logging.error('Error updating schema at %s: %s'%(self.absolute_url(), e))
return False
else:
logging.debug("schema for %s is up to date"%self.absolute_url())
return True
请注意,这是 Plone 2.5.3,与我在 plone 3 中挖掘的内容略有不同。对于我已经自定义了 processForm 的一些对象,我在那里执行升级,以便表单可以显示新字段并得到处理。对于其他只是在 at_post_edit_script 钩子中的人,因为那些通常没有大型重要的架构升级。此外,表单处理是网站中最慢的部分,因此用户体验不会受到太大影响。
它很老套,但不会导致 I/O 挥霍,并且适用于所有版本的对象。我要买它!
尽管您没有解释“跪下”是什么意思,但我猜您的内存不足。如果是这样,那可能是脚本没有将更改提交到磁盘的问题。在循环中添加一个 transaction.commit() (最好通过测试只做每 100 次或 1000 次)应该可以解决这个问题。
编辑:所以我错了,这不是内存问题。原型更新程序似乎做了正确的事情。