2009-07-23 6 views
5

私はplone archetypes(plone 2.5.X)に基づいて数十万のオブジェクトを持っており、それらのアーキタイプのスキーマを最新に更新する必要があります。アーキタイプのスキーマ移行ツールは、小/中規模のオブジェクトには最適ですが、私のサーバーをすべて移植しようとしています。私は一度に1つのオブジェクトのスキーマを更新できるようにしたい、潜在的に取得されたオブジェクトとして - それは可能ですか?そうでない場合は、大規模なploneサイトでアーキタイプのスキーマを更新する他の方法はありますか?ploneでオンデマンドで単一のアーキタイプオブジェクトのスキーマを更新するにはどうすればよいですか?

ありがとうございます!

+0

ご迷惑をおかけして、ご迷惑をおかけしております。 archetypes.schemaextenderはここであなたを助けません。私は私の答えを削除するために投票しました。 –

+0

Lennarts anwerに関するコメントがあれば、それはZEOクライアントを追加してそこの移行を行うオプションですか?これはサイトのユーザビリティへの影響が、同じインスタンス上でのマイグレーションのホスティングおよびマイグレーションよりも少ないかもしれません。 (あなたが現在行っていることを前提としています) –

+0

はい、現在はあまりにも多くのデータが残念です。実際のリクエストがあれば、必要なオブジェクトを取得するのにはかなりの時間がかかります。その散発的なもちろん。 2つの短いリクエストと5つの超長いリクエストです。 そのバマーは単純な怠惰なアップグレードではないようです。私がこのプロセスについてもっと理解していれば、私は喜んで書くだろうが、少しは謎に包まれている。私が期待している柔軟性のあるデータ全体には適合しないので、驚くべきことです。 ありがとうございます! – eleddy

答えて

0

「膝を持っていく」という意味ではありませんが、私はあなたの記憶がなくなったと推測します。もしそうなら、おそらくディスクへの変更をコミットしないスクリプトの問題でしょう。ループ内にtransaction.commit()を追加すると(100回目または1000回目ごとにテストするのが望ましい)、それを修正する必要があります。

編集:私は間違っていたので、それは記憶上の問題ではありませんでした。 archetypes updaterが正しいことをするようです。これはPloneの2.5.3と私はPloneのを掘りたものを3つのルックスからのものであることを

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 

注:

+0

残念なことに、それだけではメモリの問題ではありません。このアップデートによってロード(ディスクIO)が大幅に増加し、エンドユーザーは更新の影響をスローダウンとして認識します。計画停止の可能性は常にありますが、私は愚かなスキーマ更新のためにそれを避けようとしています。 私はちょうど標準的なarchetypeツールの更新コードを実行していて、単一のアイテムを更新する方法を見つけることができないようです。そうでなければ、ループとコミットを楽しく書くでしょう。あなたはそのループを書く方法の例を投稿できますか? ありがとう! – eleddy

+0

もちろん、IOはスパイクになるでしょう。ディスクに書き込むことなくデータベースを大量に更新できると思いますか?あなたは実際に本当の問題を抱えているようではありません。 archetypesのアップグレードを実行します。 –

+0

もちろん、顧客に支払う時間が何時間も間違いの応答時間を受け取るか、完全な停止が発生すると問題になります。一度に1つのアイテムをアップグレードすることを要求するのは非常に公正だと思うし、これはコードの小さなスニペットで簡単な答えと思った。それが不可能な場合は不可能で、私は他のオプションを見てみるでしょう。私はここでコードを探しています - 私の問題が何であるかについての講義ではありません。 – eleddy

5

2.5カタログコードを掘り後、私は最終的に怠惰なスキーマの更新に答えを見つけましたわずかに異なる。既にprocessFormをカスタマイズしたオブジェクトの場合は、そこでアップグレードを実行して、フォームが新しいフィールドを表示し、処理されるようにします。 at_post_edit_scriptフック内の他の人にとっては、通常はメジャーなスキーマアップグレードがないためです。さらに、フォーム処理は、サイトの中で最も遅い部分であるため、ユーザーエクスペリエンスはそれほど大きな影響を受けません。

ハックですが、I/Oの跳躍を起こさず、オブジェクトのすべてのバージョンで動作します。買います!

+0

どのように/あなたはそのコードにフックしていますか? – rjmunro

+0

@rjmunro私はカスタムアーキタイプのコードを持っていますが、アップグレードが必要な速さに応じて別の場所に配置します。ほとんどの場合、at_post_editフックが置かれます。あるケースでは、編集前にアップグレードを実行したいので、編集前にアップグレードするようにprocessFormを上書きしました。こうすることで、新しいスキーマ・コンテンツを手動で編集フォームに追加して、それを取らないことを心配する必要がなくなります。私はまた、そのような場合にのみワークフローを更新するために同様のことを行いました。ビューテンプレートの上部にあるスクリプトを呼び出し、ビューを更新します。コード例が必要な場合はお知らせください:) – eleddy

関連する問題