1

I found a strange behavior in the way Magento (EE 1.12) housekeeps the catalog_product_super_link table. When an associated simple product is deleted without being disassociated first, the entry corresponding to this link remains. Furthermore, when the disassociated configurable product is re-saved, the orphaned rows remain.

To replicate this, please try

  1. Create a test configurable product and simple product

  2. Associate the two.

  3. Delete the simple product without disassociating.

  4. Check the DB table with the following query.

    select l.*, p.sku
    from catalog_product_super_link as l
        left join catalog_product_entity as p
            on l.product_id = p.entity_id
    where l.parent_id = 1936;
    

And you'll get something like below where the NULL entries are former associations.

1769 1937 1936 NULL

1770 1938 1936 NULL

1771 1939 1936 NULL

1772 1940 1936 NULL

1773 1941 1936 bag-001

1776 1950 1936 bag-002

Is this normal?

1 Answer 1

2

Are you sure this is standard behavior?
I took a look at the table structure and it has 2 constaints on it.

CREATE TABLE `catalog_product_super_link` (                                                                                                                                        
    `link_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Link ID',                                                                                                            
    `product_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Product ID',                                                                                                         
    `parent_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Parent ID',                                                                                                           
    PRIMARY KEY (`link_id`),                                                                                                                                                         
    UNIQUE KEY `UNQ_CATALOG_PRODUCT_SUPER_LINK_PRODUCT_ID_PARENT_ID` (`product_id`,`parent_id`),                                                                                     
    KEY `IDX_CATALOG_PRODUCT_SUPER_LINK_PARENT_ID` (`parent_id`),                                                                                                                    
    KEY `IDX_CATALOG_PRODUCT_SUPER_LINK_PRODUCT_ID` (`product_id`),                                                                                                                  
    CONSTRAINT `FK_CAT_PRD_SPR_LNK_PARENT_ID_CAT_PRD_ENTT_ENTT_ID` FOREIGN KEY (`parent_id`) REFERENCES `catalog_product_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE CASCADE,  
    CONSTRAINT `FK_CAT_PRD_SPR_LNK_PRD_ID_CAT_PRD_ENTT_ENTT_ID` FOREIGN KEY (`product_id`) REFERENCES `catalog_product_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE CASCADE     
) ENGINE=InnoDB;

This means that if a product is deleted (so the row is removed from catalog_product_entity) any row in the catalog_product_super_link that has that product id in the columns parent_id or entity_id will be deleted.

Check if you didn't lose the constraints on a database migration.

1
  • You're right about the constraints. I no longer have access to that database in question, but I wouldn't be surprised if constraints were removed.
    – laketuna
    Mar 17, 2015 at 14:05

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.