3

RESTful Web サービスを介してサードパーティ システムに注文データを送信するスクリプトがあります。このシステムは、各リクエストで一意の ID を送信することを要求します。この ID は、次から自動インクリメントされます。

これは、Magento のcore_config_dataテーブルに変数を追加することで実装しました。コードの一部として、ID の次の値を取得するために以下の関数が呼び出され、次のリクエストのために値がインクリメントされます。

class MyProject
{
    public function getNextApiId() {
        // Get the next ID.
        $id = Mage::getStoreConfig('myproject/next_api_id');

        // Increment the stored value for next time.
        $nextId = $id + 1; // change $id++ by $id + 1 otherwise the result of $nextId = $id - 1;
        Mage::getModel('core/config')->saveConfig('myproject/next_api_id',$nextId);

        // Refresh the config.
        Mage::getConfig()->cleanCache();
        Mage::getConfig()->reinit();

        // Return the ID.
        return $id;
    }
}

スクリプトで 1 つの要求を送信すると、これは正常に機能します。値が増加し、次の ID がスクリプトの次の実行に使用されます。

ただし、同じスクリプト実行内のループで複数の要求を処理している場合、値はキャッシュされているように見えます。以下のコードは、簡潔にするために簡略化していますが、一般的なフローを示しています。

function sendRequest($item) {
    $apiId = $MyProject->getNextApiId();

    // Build and send request body
}

foreach($items as $item) {
    sendRequest($item);
}

これにより、最初の ID 番号がすべての に使用されます$items。

および構成キャッシュを更新しようとしてもcleanCache()、reinit()まったく機能していないようです。値がキャッシュされないようにする方法についてのアイデアはありますか?

4

5 に答える 5

6

キャッシュは別の方法で消去する必要があります。ストアのキャッシュをリセットして、ループの原因を再度初期化する必要があります。ループがなかった場合、それも消去されますが、キャッシュを初期化するショップの 2 番目の URL リクエストが必要です。

代わりにこれを試してください：

function getNextApiId() {
    // Get the next ID.
    $id = Mage::getStoreConfig('myproject/next_api_id');

    // Increment the stored value for next time.
    $nextId = $id + 1;

    Mage::getConfig()->saveConfig('myproject/next_api_id',$nextId);

    // Refresh the config.
    Mage::app()->getStore()->resetConfig();

    // Return the ID.
    return $id;
}
于 2013-01-04T17:13:56.850 に答える
4

Magento 構成は、頻繁に変更されない値、何かの動作を変更する値を対象としています。この値を構成に保存することは目的に合わないだけでなく、サイトにパフォーマンスの問題をもたらします。構成キャッシュをクリアするたびに、サイトは構成ファイルを、キャッシュに保存されているキャッシュされた XML ドキュメントにリレーする必要があり、これにより、サイトの読み込み時間に不要な遅延が発生します。

私の提案は、次のいずれかを行うことです。

を。プロセス ID と UNIX タイムスタンプ (マイクロ秒) を組み込んだ、生成されたパターンに基づく UID を使用します。

b. コア変数モデルを使用して、値を次の場所に保存します。Mage::getModel('core/variable')->loadByCode('myproject_next_api_id');

オプション「b」に関する私の警告は、このスクリプトが複数のインスタンスを同時に実行している可能性がある場合、競合状態に陥り、カスタムのアトミック更新クエリを介して更新するデータベースに ID を記録に保存する必要があることです。 .

于 2013-01-07T14:38:08.827 に答える
4

一意の ID を API に渡す必要があるだけなのに、データベースの読み取りと書き込み、構成キャッシュのクリアなど、わざわざわざわざ行く必要があるのでしょうか。

PHP でこれを行う方法はたくさんありますが、その 1 つを次に示します。

$uniqueId = uniqid();

http://php.net/manual/en/function.uniqid.php

それ以外の場合、質問の方法を使用して ID を作成する必要がある場合は、構成を正しく保存していることを確認してください。

Mage::getConfig()
    ->saveConfig('myproject/next_api_id', $nextId)
    ->cleanCache();
Mage::app()->reinitStores();
于 2013-01-04T17:19:28.013 に答える
0

選択された回答、およびキャッシュのクリアを伴う他の多くの回答は、完全に恥ずべきMage::app()->getStore()->resetConfig();ことMage::getConfig()->reinit();です。

これにより、Magento が XML 構成を完全に再解析するようになりますが、これは非常に遅く、プラグインとその構成ファイルの数が増えるほど遅くなります。

一部のプラグイン開発者がこのようなものをコピーして貼り付け、それらのプラグインを使用する人に多大なパフォーマンスの問題をもたらすのを見てきました. これらのコードを単に使用するだけでなく (それも)、要求ごとに呼び出されるコードを巧みに詰め込み、構成キャッシュの効率を効果的に 0 に低下させます!

変更内容を簡単に更新できるのに、構成キャッシュ全体をクリアする必要はありません。

Mage::app()->getStore()->setConfig('foo', 'bar'); 
Mage::getConfig()->saveConfig('foo', 'bar')->saveCache();

最初の行は、リクエストのライフサイクルのみの構成項目を更新します (ランタイム キャッシュ)

2 行目では、同じ内容が確実にcore_config_dataキャッシュに保存され、更新されます。

しかし、いずれにせよ、@davidalger による回答core_config_dataは、めったに変更されないデータを対象としていると正当に述べています。

于 2019-10-31T11:36:29.873 に答える