Skip to main content

Why is the Relation Between a Configurable Product and a Simple Product Stored Twice?

Image
By User


Deep dive on the Magento internals here, not looking for a solution to a concrete problem, just trying to understand some implementation details.



When you create a Configurable Product in Magento, and then create child Simple Products to implement things like shirt size, color, etc., Magento stores this relationship in two separate tables. 





catalog_product_relation

catalog_product_superlink_table


Why are these relationships stored twice?



Is this legacy code, or is there a semantic distinction between a product relation link and a product "superlink" link?



Does the system expect these to be the same, or is it a valid object state to have these tables representing different parent/child relationships?


Source: Tips4all, CCNA FINAL EXAM
Labels:

Comments

  1. UserMay 10, 2012 at 3:07 AM

    Why is great question. The catalog_product_super_link table only contains data related to configurable products. catalog_product_relation also contains the relation information for bundled and grouped products, in addition to the configurable relations.

    All the business logic revolving around configurable products refers to the catalog_product_super_*tables, e.g. finding the configurable attributes and price updates for a configurable product.

    The catalog_product_relation table in contrast is used by classes not specific to configurable products, like the abstract catalog product indexer classes.

    It seems that the Magento core team wanted to separate the logically distinct functionality not only into separate PHP classes, but also into separate database tables. Possible advantages? I guess theoretically it is easier this way to change the configurable product implementation without disrupting the indexer implementation.

    This is just a guess - I haven't confirmed that or spoken with someone who "knows" (mental-note-for-imagine)

    ReplyDelete

Post a Comment

Popular posts from this blog

Why is this Javascript much *slower* than its jQuery equivalent?

By User
I have a HTML list of about 500 items and a "filter" box above it. I started by using jQuery to filter the list when I typed a letter (timing code added later): $('#filter').keyup( function() { var jqStart = (new Date).getTime(); var search = $(this).val().toLowerCase(); var $list = $('ul.ablist > li'); $list.each( function() { if ( $(this).text().toLowerCase().indexOf(search) === -1 ) $(this).hide(); else $(this).show(); } ); console.log('Time: ' + ((new Date).getTime() - jqStart)); } ); However, there was a couple of seconds delay after typing each letter (particularly the first letter). So I thought it may be slightly quicker if I used plain Javascript (I read recently that jQuery's each function is particularly slow). Here's my JS equivalent: document.getElementById('filter').addEventListener( 'keyup', function () { var jsStart = (new Date).getTime()...
3 comments
Read more