Php Magento:检索未缓存的系统配置值

我有一个脚本，通过RESTfulWeb服务将订单数据发送到第三方系统。此系统要求随每个请求发送一个唯一的ID，该ID从下一个请求开始自动递增

我通过在Magento的

core\u config\u data

表中为此添加一个变量来实现这一点，作为我代码的一部分，下面的函数被调用以获取ID的下一个值，并为下一个请求增加它

classmyproject
{
公共函数getNextApiId（）{
//获取下一个ID。
$id=Mage:：getStoreConfig（'myproject/next_api_id'）；
//为下次增加存储值。
$nextId=$id+1；//将$id++更改为$id+1，否则$nextId=$id-1的结果；
Mage:：getModel（'core/config'）->saveConfig（'myproject/next_api_id'，$nextId）；
//刷新配置。
Mage:：getConfig（）->cleanCache（）；
Mage:：getConfig（）->reinit（）；
//返回ID。
返回$id；
}
}

如果我用脚本发送一个请求，效果很好-该值将递增，下一个ID将用于脚本的下一次执行

但是，如果在同一个脚本执行过程中在循环中处理多个请求，则该值似乎会被缓存。下面的代码应该说明一般的流程，尽管为了简洁起见，我对其进行了简化：

函数sendRequest（$item）{
$apid=$MyProject->getNextApiId（）；
//生成并发送请求主体
}
foreach（$items作为$item）{
发送请求（项目）；
}

这将导致所有

$items

都使用初始ID号

---

刷新配置缓存的

cleanCache（）

和

reinit（）

尝试似乎根本不起作用。有没有关于如何停止缓存该值的想法？

必须以不同的方式清理缓存，您必须重置存储区的缓存并再次初始化它，因为存在循环。如果你没有一个循环，它也会被清除，但是它需要商店的第二个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;
}

---

如果您只需要向api传递一个唯一的id，那么为什么还要这么麻烦呢？读写db，清除配置缓存等等

在PHP中有很多方法可以做到这一点，下面是一种：

$uniqueId = uniqid();

否则，如果必须使用问题中的方法创建id，请确保正确保存配置：

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

---

Magento配置用于不经常更改的值，这些值会更改某些对象的行为。将此值存储在配置中不仅与目的不符，而且还会给站点带来性能问题。每次清除配置缓存时，站点都必须将配置文件重新层到缓存中存储的缓存XML文档中，这将给站点的加载时间带来不必要的延迟

我的建议是采取以下措施之一：

a。根据包含进程ID和unix时间戳（微秒）的生成模式使用UID

b。使用核心变量模型将您的值存储在：

Mage:：getModel（'core/variable'）->loadByCode（'myproject_next_api_id'）

我对选项“b”的警告是，如果您有可能同时运行此脚本的多个实例，您将遇到竞争条件，这需要将ID存储在数据库中，并通过自定义原子更新查询进行更新。
这里有一个简单的替代方案：

protected function _getLastId()
{
    $id = Mage::app()->useCache('config') ?
        Mage::getResourceModel('core/config_data_collection')
            ->addFieldToFilter('path', self::XML_PATH_LAST_ID)
            //->addFieldToFilter('scope', $scope)
            //->addFieldToFilter('scope_id', $scopeId)
            ->getFirstItem()
            ->getValue() :
        Mage::getStoreConfig(self::XML_PATH_LAST_ID);
    return (int) $id;
}

选择的答案，以及许多其他涉及清除缓存的答案，都是一个耻辱，因为
Mage:：app（）->getStore（）->resetConfig（）将导致
Mage:：getConfig（）->reinit（）这是您最应该调用的内容。。。从来没有

它将触发Magento完全重新解析XML配置，这是非常缓慢的，而且随着插件及其配置文件数量的增加，速度会越来越慢

我见过一些插件开发者复制这种粘贴的东西，结果给使用这些插件的人带来了巨大的性能问题。不仅通过使用这些代码（这也是），而且还巧妙地管理填充这些代码以在每次请求时调用，有效地导致配置缓存效率下降到0

如果可以简单地更新更改的内容，为什么要清除整个配置缓存

Mage:：app（）->getStore（）->setConfig（'foo'，'bar'）；
Mage:：getConfig（）->saveConfig（'foo'，'bar'）->saveCache（）；

第一行仅更新请求生命周期的配置项（运行时缓存）

第二行确保将其保存到
core\u config\u data
并更新缓存

但不管怎样，@davidalger的回答都正确地指出，
core\u config\u data
用于很少更改数据。
@SylvainRayé恐怕不是，对不起。代码的一部分是类似的，是的，不幸的是没有办法解决这个问题，因为它是相对标准的代码，没有真正的替代品。您的解决方案中还遗漏了一些重要代码。好吧，我向您道歉。我又查了一遍，你是对的。然而，作者的代码中有一个bug。它应该是
$id+1
而不是
$id++
，否则结果将是
$nextId=$id-1
错误的好位置。在减少这里使用的代码时，我犯了这个错误。我的原始代码有
$nextId=$id+1。唯一ID需要从上一个值递增，这在我最初的问题中不清楚。已进行编辑以反映这一点。我会给reinitStores（）
一个机会，看看它是否有什么不同。投票失败的原因是什么？看起来与我最初拥有的类似，不过它使用的是
Mage:：app（）->getConfig（）
，而不是
Mage:：getConfig（）
。可能会有所不同，我会尝试一下。@CVM很高兴能解释为什么你投了反对票。是，
Mage:：app(