3

問題の核心は、GenericSetupプロファイルが付加的であるということです。プロファイルを適用するだけでは製品をアップグレードできない場合があり、プロファイルのチェーン全体を特定の順序で適用する必要があります。

たとえば、S1、S2、....、SNなどの独立したサイトポリシーが多数あるとします（そのうちの1つだけがploneインスタンスに適用されます）。そして、いくつかの製品、たとえばAとB。たとえば、これらすべてのS1-SN、A、およびBには、メタデータの依存関係が次のようになります。Sn-> A-> B

彼らがregistry.xmlを処理し、途中で何かをオーバーライドするとします。（typeinfoやその他のプロファイル手順でも同じことが言えます）。S1でオーバーライドされる場合とされない場合がある、製品Aで何かが変更された場合、S1サイトのボタンを押すと、独自のポリシーオーバーライドが失われるため、Aのアップグレード手順を実行することはできません。ただし、Aが変更されたという理由だけで、すべてのS1-SNのアップグレード手順を作成することは重要です。

レジストリの更新を特定の順序、つまりB、A、Snで適用することで問題全体が解決される場合に、少なくとも上記の場合にアップグレードを行うための賢い方法はありますか。（それでも、いくつかの難しいケースがあるかもしれません）？

パッケージAはS1（またはS2またはサイトポリシーが何であれ）を認識していないため、1つの解決策は、アップグレードのチェーンについて明示的な知識を持つ可能性のある「スーパーパッケージ」を作成することです。しかし、結果のプロファイルを常にポリシーに適用する以外に、他の解決策はありますか？

（簡単にするために、いくつかの変更がWebを介して行われる可能性があることを忘れてください）

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 に答える