It is strange! I just copy your logic and test it, not worked after that I start to debug model load flow, edited and review logs. So finally it worked! But my code same as yours:
Customweb_Saferpay module:
<models>
<saferpay>
<class>Customweb_Saferpay_Model</class>
<resourceModel>saferpay_mysql4</resourceModel>
</saferpay>
</models>
Etagen_SaferpayGuestOrderFix module:
<models>
<etagen_saferpayguestorderfix>
<class>Etagen_SaferpayGuestOrderFix_Model</class>
</etagen_saferpayguestorderfix>
<saferpay>
<rewrite>
<method>Etagen_SaferpayGuestOrderFix_Model_Method</method>
</rewrite>
</saferpay>
</models>
Method.php:
class Customweb_Saferpay_Model_Method
{
public function getPaymentPageLink()
{
return get_class($this);
}
}
Second one:
class Etagen_SaferpayGuestOrderFix_Model_Method extends Customweb_Saferpay_Model_Method{
}
Testing code:
$model = Mage::getModel('saferpay/method');
echo $model->getPaymentPageLink();
But result sometimes correct, sometimes incorrect (incorrect after cleaning of cache).
Finally I found such xml config and it gives correct result alltime:
<models>
<etagen_saferpayguestorderfix>
<class>Etagen_SaferpayGuestOrderFix_Model</class>
</etagen_saferpayguestorderfix>
<saferpay>
<deprecatedNode>etagen_saferpay</deprecatedNode>
</saferpay>
<etagen_saferpay>
<rewrite>
<method>Etagen_SaferpayGuestOrderFix_Model_Method</method>
</rewrite>
</etagen_saferpay>
</models>
Who reads this question, please, test it and I can't find reason of such behavior of Magento. Location of models are located in same code pool and maybe this is reason of such understandable situation.
Your customizations should be as easy to maintain as possible - especially for upgrades. This is likely best accomplished by identifying the best integration points and customizing core functionality when necessary.
When you rewrite a class via the configuration, you are changing the class instantiated, assumedly to customize a part of some core class behavior. This is more appropriate from a programmatic standpoint than owning the entire definition.
Rewrites won't work for parent classes or for library classes (e.g. Varien_Data_Collection_Db
), so changes to these must be implemented by transferrance to local code pool. I'm very curious to know what you want to change with the DB collection superclass.
While blocks, helpers, and models all have a similar xpath for rewriting, e.g.
global>[blocks|helpers|models]>[class group]>rewrite>[class id]
resource models require a slightly different mapping. I can tell you are using a pre-MDBM release of Magento (CE <1.6), so your rewrite mappings would be as follows:
<global>
<models>
<catalog>
<rewrite>
<layer_filter_attribute></layer_filter_attribute>
</rewrite>
</catalog>
<catalog_resource_eav_mysql4>
<rewrite>
<layer_filter_attribute></layer_filter_attribute>
<product_collection></product_collection>
</rewrite>
</catalog_resource_eav_mysql4>
</models>
</global>
As I said, I am quite curious to know your reasons for rewriting the resource models.
Best Answer
Method
getSelectCountSql()
is overwritten in a lot of collections likeMage_Sales_Model_Resource_Order_Collection
for example.So if you need to change the behavior of
getSelectCountSql()
for some collection, you can easily do that in your collection class.But do not do that in
Varien_Data_Collection_Db
because it will change the behavior of this method for all collections.