3

问题的核心是 GenericSetup 配置文件是附加的。有时产品不能通过简单的应用配置文件升级，整个配置文件链需要按照一定的顺序应用。

例如，假设我们有很多独立的站点策略（其中只有一个应用于 plone 实例）：S1、S2、....、SN。还有一些产品，比如 A 和 B。例如，所有这些 S1-SN、A 和 B 都具有元数据依赖关系，如下所示：Sn -> A -> B

假设他们处理registry.xml 并在此过程中覆盖某些内容。（typeinfo 和其他一些配置文件步骤也是如此）。如果产品 A 发生了一些变化，在 S1 中可能会或可能不会被覆盖，我们不能只为 A 执行升级步骤，因为当我们按下 S1 站点上的按钮时，它自己的策略覆盖将丢失。但是，仅仅因为 A.

至少对于上面描述的情况，是否有任何聪明的方法来进行升级，当整个问题可以通过按特定顺序应用注册表更新来解决时，即：B、A、Sn。（即使那样，可能会有一些困难的情况）？

由于包 A 不知道 S1（或 S2 或任何站点策略），一种解决方案是制作一些“超级包”，它可以明确了解这些升级链。但是，除了始终将生成的配置文件放入策略之外，还有其他解决方案吗？

（为简单起见，让我们忘记一些更改可以通过网络完成）

4

2 回答 2

1

这实际上已经在 GS 中，尽管不幸的是，并非所有产品都使用它。解决方案在于使用 GS 的upgradeStep.

假设您将配置文件的元数据从版本 1 更改为 2。在您的 zcml 中，您注册一个升级步骤，如下所示：

  <genericsetup:upgradeStep
      title="Upgrade myproduct from revision 1 to 2"
      description=""
      source="1"
      destination="2"
      handler="myproduct.one_to_two.upgrade"
      sortkey="1"
      profile="myproduct:default"
      />

在one_to_two.py你会有

def upgrade(context):
    registry = getUtility(IRegistry)
    if 'foo' in registry:
        do_stuff()

在那里，您还可以重新运行特定的导入步骤，例如：

context.runImportStepFromProfile('profile-myproduct:default','actions')

升级产品时，只会应用升级步骤处理程序中指定的内容，这正是您所需要的。

关于这里的所有文档。

于 2012-05-21T18:47:24.303 回答
0

决定使用自定义解决方案，具有帮助功能，使常见的升级任务更容易。不能解决所有问题，但有助于部署。

于 2012-07-30T07:54:16.117 回答