php - Magento 集合过滤功能

Question

处理 Magento 集合时 addAttributeToFilter() 和 addFieldToFilter() 有什么区别？它与该值是否为 eav_attribute 有关系吗？

编辑:根据 http://www.magentocommerce.com/wiki/5_-_modules_and_development/catalog/using_collections_in_magento :

addFieldToFilter($attribute, $condition=null) -- alias for addAttributeToFilter()

有人可以证实这一点吗？

Answer 1

抱歉，这里没有不会误导或混淆事物的简短答案。

重点#1:Magento 核心团队不愿意从源代码树中删除或重命名方法。创业文化意味着他们避开测试，加上作为一个公共(public)项目，这意味着他们无法控制人们用他们的产品做什么。他们不会删除方法并冒破坏事物的风险，而是将调用新方法的方法留在原处。这样，即使有调用该方法的旧代码，它们也会被覆盖。

重点#2:集合继承链是扭曲的，并且在代码库的某些部分应用不一致。这正在清理中，但它仍然很容易让你陷入循环。

要点#3:我在推测这其中有多少是要使用和发生的。我不是这里的最终权威，我只是试图理解它的人。以下具体引用1.6，但概念适用于所有版本

所有集合都继承自类 Varien_Data_Collection_Db .这是对“收集从数据库加载的一系列对象”的基本概念进行建模的类。这个类只有一个方法 addFieldToFilter .

public function addFieldToFilter($field, $condition=null)
{
    $field = $this->_getMappedField($field);
    $this->_select->where($this->_getConditionSql($field, $condition), null, Varien_Db_Select::TYPE_CONDITION);
    return $this;
}

这是一个简单的实现，它向理论查询添加了一个 where 子句。

接下来，还有 两个具有 Varien_Data_Collection_Db 的抽象类作为祖先。 Mage_Core_Model_Resource_Db_Collection_Abstract和 Mage_Eav_Model_Entity_Collection_Abstract .
Mage_Core_Model_Resource_Db_Collection_Abstract是“常规、非 EAV 模型”的集合类。它既没有 addFieldToFilter方法或 addAttributeToFilter方法。它依赖于基础 Varien_Data_Collection_Db 中的实现类(class)。
Mage_Eav_Model_Entity_Collection_Abstract是 EAV 模型的集合类。它有一个 addAttributeToFilter方法，比较复杂。

public function addAttributeToFilter($attribute, $condition = null, $joinType = 'inner')
{
    if ($attribute === null) {
        $this->getSelect();
        return $this;
    }

    if (is_numeric($attribute)) {
        $attribute = $this->getEntity()->getAttribute($attribute)->getAttributeCode();
    } else if ($attribute instanceof Mage_Eav_Model_Entity_Attribute_Interface) {
        $attribute = $attribute->getAttributeCode();
    }

    if (is_array($attribute)) {
        $sqlArr = array();
        foreach ($attribute as $condition) {
            $sqlArr[] = $this->_getAttributeConditionSql($condition['attribute'], $condition, $joinType);
        }
        $conditionSql = '('.implode(') OR (', $sqlArr).')';
    } else if (is_string($attribute)) {
        if ($condition === null) {
            $condition = '';
        }
        $conditionSql = $this->_getAttributeConditionSql($attribute, $condition, $joinType);
    }

    if (!empty($conditionSql)) {
        $this->getSelect()->where($conditionSql, null, Varien_Db_Select::TYPE_CONDITION);
    } else {
        Mage::throwException('Invalid attribute identifier for filter ('.get_class($attribute).')');
    }

    return $this;
}

那是因为属性查询是 不是 一个直接的“where”查询。此外，此方法旨在采用属性名称 或 属性数据库 ID， 或 一个实例化的属性对象。您是 不是 向过滤器添加一个字段，就是向过滤器添加一个属性。因此，根据 EAV 的实现以及属性存储在哪个表中，您需要添加不同的 SQL 代码(在主表上的直接 where 查询，添加一个连接表的 where 等)

这就产生了一个问题。因为这个 EAV 集合对象继承自基础集合对象， addFieldToFilter仍然存在，并且仍然会向 EAV 查询添加一个基本的 where 条件，这可能会使最终用户不按照他们的想法去做。所以EAV收藏类也有这个

public function addFieldToFilter($attribute, $condition = null)
{
    return $this->addAttributeToFilter($attribute, $condition);
}

它包含对 addFieldToFilter 的任何调用至 addAttributeToFilter (再次，在 EAV 模型上)。所以，如果你有 EAV 模型，你可以使用 addFieldToFilter或 addAttributeToFilter .如果您使用的是常规模型，您可以 只有调用 addFieldToFilter , addAttributeToFilter不存在。

理想情况下，方法名称从一开始就统一，但是一旦拆分发生，Magento 团队选择继续支持拆分以支持向后兼容。

等等，还有更多

代码库中还有两个集合继承了 直接来自 Varien_Data_Collection_Db。这些是 Mage_Sales_Model_Resource_Sale_Collection和 Mage_Review_Model_Resource_Review_Summary_Collection .这个数字在 1.6 之前的 Magento CE 版本中更高。虽然这不会影响过滤的问题，但它确实混淆了继承链，所以你应该注意它。

许多非 EAV 集合将实现自己的 addFieldToFilter对变量进行完整性检查，或者如果查询参数做的有点不标准，则稍微调整一下。

EAV 系列也通过重新定义 addAttributeToFilter 来参与这一行为。 .同样，这样做是为了添加不适合基本 Magento 集合加载的自定义逻辑。