Part 1: Catalog System

1When you export the catalog, you might assume that you will export all of the asset information attached to your nodes and entries. However, due to the limitations of the content type models, which is mentioned later, when you export inside Commerce Manager, those information will be lost. We will have an exercise of writing a small tool to export the catalog with the asset information later.↩

2You will export all of the warehouses and metaclasses in the system, even if the catalog being export does not use those. That’s the default behavior. You might argue that it’s not very reasonable. I think it’s up to your point of view to see if the system should be exporting those or not. If you want a clear “catalog”, follow the instruction in my blog post.↩

3In earlier versions of Commerce, such as R3, there was another type of entry, Dynamic Package, which allows customer to adjust some items in the package. The concept is hardly used and was removed in later releases.↩

4It’s CatalogContentProvider which does the hard work of processing catalog contents, but you should never work with it directly. The only API:s you should work with are IContentLoader (for content loading) and IContentRepository (for content loading and saving). Those will make sure to call the responsible content provider to handle the content it’s processing (and doing other stuffs such as caching, raising events or so). I will even make a bold statement here: if you’re working with CatalogContentProvider directly, you are (probably) doing it wrong. However, I think it deserves an honorable mention for its unsung works. You’re the silent hero, CatalogContentProvider.↩

5It might be a little confusing with the term of CatalogContent. It can mean either catalog content in general, or a content of catalog.↩

6When the CatalogContentProvider was designed (it was called CommerceContentProvider at that time, prior to Commerce R3), there was an idea of having a forth part in the ContentReference to indicate the content type, so it’ll become 12_3_CatalogContent_Entry, or 12_3_CatalogContent_Node. The idea was shot down by the architects, so we have less “human-readable” ContentReference as it is today. However, the ContentReference was not designed to be human-readable in mind (although it’s quite easy to do so), it’s the systems which need to understand it.↩

7(yes, it’s not the best naming to have two classes named exactly the same in your framework, even if they are in two separated assemblies. I must admit I am still confused by them, and it takes me a few seconds to navigate to the correct class. However, they have been there since forever and any changes would become a big breaking change. We’ll have to live with it for now.)↩

8The funny thing is the limitation only applies if you have the CatalogContentType attribute (which will be explained later). If you have no such attribute, it’ll still work, but when you save MyExtendedProperty, it will be saved to nowhere.↩

9Since Commerce 9, the Money column has been there. But it turned out to have not enough precision in some case, so Decimal column was added later (Commerce 9.7) and all the data in Money column has been moved to the new column. Since 9.7, all decimal values are stored in Decimal column.↩

10You can read more about Dynamic Data Store here. If you want to take a look at how catalog versions were stored (Given you have Commerce 8 databases), check tblBigTable in CMS database. The catalog content drafts are in CatalogContentDraftStore store.↩