获取相关对象时，Propel是否缓存条件？

我有一个Propel 1.6生成的类组，它与Inits有关，并且Inits有与它们相关的Resps。非常简单。获取相关对象时，Propel是否缓存条件？

我不明白这两个Propel代码之间的区别。在第一个循环中，我重新创建了$notDeleted标准。这段代码做我想要的 - 它将所有的Resps放入$data阵列中。

foreach ($group->getInits() as $init) { 
    $notDeleted = RespQuery::create()->filterByIsDeleted(false); 
    foreach ($init->getResps($notDeleted) as $resp) { 
     $data[] = $resp; 
    } 
}

在这里，在第二个代码，我有$notDeleted标准拉出循环，为的（我认为是）很明显效率的原因。此代码不按我想要的方式工作 - 它仅从Inits中的一个获取Resps。

$notDeleted = RespQuery::create()->filterByIsDeleted(false); 
foreach ($group->getInits() as $init) { 
    foreach ($init->getResps($notDeleted) as $resp) { 
     $data[] = $resp; 
    } 
}

我想这一定是什么做的getResps()方法如何存储的结果，但事实并非文档或代码如何在该方法读取。文档和代码表示，如果传递到getResps()的标准不为null，它将始终从数据库获取结果。也许一些其他Propel缓存？

来源

2013-03-15 matt

（首先，我猜你的意思是使用$init与您的循环$initiative这还是有我们没有在这里看到一些其他的代码。）

这里是我的猜测：在你的第二个例子中，你拉出$notDeletedCriteria对象，但每次通过内部foreach调用getResps($notDeleted)将使得Propel在Criteria实例上使用当前的Init实例执行filterByInit()实例。这将为SQL添加一个新的WHERE条件，但显然Resp只能有一个Init.Id值，因此是唯一的结果。

我不认为有很好的理由可以解决这个问题，但是Propel只是创建一个新的Criteria对象，克隆你传入的对象 - 因此没有保存真正的内存。

来源

2013-03-15 20:07:45 jakerella

（是的，你是对的变量名称，感谢j0k清理它。）我有点看到你在说什么。但我会期望Propel生成一个新的WHERE Init.Id =？每次在循环中调节。但我猜这是不是这样做？ – matt 2013-03-15 21:26:54

我不认为这会......但我不是100％确定。还有其他的事情可以做，但即使如此，我认为这不是你的代码是罪魁祸首。 – jakerella 2013-03-15 21:47:03

获取相关对象时，Propel是否缓存条件？

回答

相关问题