Magento Collection过滤功能

处理Magento集合时，addAttributeToFilter（）和addFieldToFilter（）之间有什么区别？是否与eav_attribute值有关？

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

重点＃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类的实现。

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代码（在主表上直接查询，在其中添加一个连接表，等等）

这会产生问题。因为此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集合加载的自定义逻辑。