0

Background: I have inherited a rather large import routine running as a custom Magento module. It deals with importing products, categories, images, accessories, associations, etc....pretty much everything. Most of it is now working. However when it comes to importing Accessories I run into all sorts of Integrity constraint violations (duplicate entries) or foreign key restriction issues with tables like cataloginventory_stock_item.

Actual question: When running the catalog/product delete commands early on in the process, e.g.

 $collection = Mage::getModel('catalog/product')->getCollection();
         foreach($collection as $key=>$value)
         {
             Mage::getModel('catalog/product')->load($value->entity_id)->delete();

         }

what tables get affected by this, is it just the product_entity table or are various other product related tables in background also modified?

I am trying to work out what tables I may manually need to truncate (can this be done via a Magento model/method ?) or what ones will be affected properly along the way by the magento core.

Many thanks

Improve this question
1
  • P.S. I know that this method of deleting is dead slow but not knowing fully what is happening behind the scenes limits my desire to truncate or drop things.
    – Jon Holland
    Commented Dec 18, 2014 at 14:16

1 Answer 1

Reset to default
1

Normally you should only delete the rows from the catalog_product_entity.
If your database is not missing the foreign keys, everything should cascade nicely.

If you still want to see the tables that are involved in the product delete routine, just export your database structure and look for contraints. REFERENCEScatalog_product_entity(entity_id).

but don't use truncate. Use delete. It's slower but at least it does not behave as funny as truncate does.

Improve this answer
4
  • Thanks Marius. Truncate seems like the wrong and bad option when everything else is done procedurally via calls to the Mage Core. It just seems like not everything necessary is being cleared out.
    – Jon Holland
    Commented Dec 18, 2014 at 14:30
  • it should be, unless you are missing some foreign keys. Sometimes, if one is not careful, the FKs get lost in a migration.
    – Marius ♦
    Commented Dec 18, 2014 at 14:41
  • Unfortunately I have inherited (from my predecesser) a massive module which clears out some things then imports categories, thousands of products, product groups, associations, accessories and page content. It is a bit of a mission to work out what is going on, and when the import dies part way through it becomes difficult to locate the problem. The problem might be caused by the incompleted import run, not everything needing to be cleared in the first place, or might be legacy issues that never worked in the first place. Working on it though - slowly losing my hair.
    – Jon Holland
    Commented Dec 18, 2014 at 14:50
  • Oddly, after running the ->delete() function the catalog_product_entity table still has ~128 rows in it, all entity_type_id 4.
    – Jon Holland
    Commented Dec 18, 2014 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.