In my case I had to do some simple string replacement in the
Code column in the
CatalogEntry table. Simple enough, some basic SQL - we can all do that. The weird thing is, after executing my SQL and recycling the application pool to clear caches, I was still looking at old data in EPiServer. The reason for this is the
SerializedData column, which holds all data for that entry in a serialized form.
A simple fix for this, was simply to
UPDATE dbo.CatalogEntry SET SerializedData = NULL. When decompiling the source from Commerce it seems that
SerializedData is inspected before the normal columns for caching the catalog entry objects. If it's empty, however, it uses the raw columns instead. And as far as I've experienced, it's just as fast. And also, the first time you're saving the catalog entry after doing this, the
SerializedData column will be repopulated. In the end, no harm done.
I've been working with the site for a good few months after I did this without having any side effects, so to me it looks safe. However, I do not take any responsibility for data loss you experience. Backup your database before trying and code fearlessly.
EPiServer: Maybe you should look into removing this column completely? I'm guessing it remains from the old Mediachase system, but now that everything is included in the cache that you talk to via
IContentLoader - is this column really necessary? Also, it always falls back to the raw column values in the database. Removing it would make batch updates far, easier - and far more intuitive to work with as a developer. Plus it could save some bytes of space when the database grows bigger.