• Catalog,  Commerce,  Episerver,  Tips

    Beware of IContentLoader.GetChildren() for CatalogContent

    This is more of a self-to-note. If you are using IContentLoader.GetChildren<T>(ContentReference), one important thing to remember is this uses the current preferred language. Normally when you get children of a catalog, or a node, that would not be a problem, because a catalog entity – node or entry, will be available in every language supported by the catalog. So if you just want to get the children references, the language is not important. (Note that, if you just need the children references, IRelationRepository should be a faster, more lightweight way to go, but that’s another story). If you want to get children in a specific language – which is the most common…

  • Catalog,  Commerce,  Episerver,  Performance,  SQL Server

    A curious case of SQL execution plan, part 2

    Recently I wrote about how to look into, identify and solve the problem with a SQL Server execution plan – as you can read here: https://vimvq1987.com/curious-case-sql-execution-plan/ I have some more time to revisit the query now, and I realized I made a “small” mistake. The “optimized” query is using a Clustered Index Scan So it’s not as fast as it should be, and it will perform quite poorly in no cache scenario (when the buffer is empty, for example) – it takes about 40s to complete. Yes it’s still better than the original one, both in non cached and cached cases. But it’s not good enough. An index scan, even cached,…

  • Catalog,  Commerce,  Episerver,  Performance,  SQL Server

    A curious case of SQL execution plan

    I said this already, and I will say it again: SQL Server optimizer is smart. I can even go further and say, it’s smarter than you and me (I have no doubt that you are smart, even very, very smart 🙂 ). So most of the cases, you leave it to do whatever it thinks is the best. But there are cases SQL Server optimizer is fooled by the engine – it gets confused and chooses an sub-optimal plan, because it was given wrong, outdated, or incorrect information. That’s when you need to step in. Today I face one case like that, as reported here: http://world.episerver.com/forum/developer-forum/Episerver-Commerce/Thread-Container/2017/10/database-timeout-on-productvariant-update/

  • Catalog,  Commerce,  Episerver,  Performance,  Tips

    Episerver Commerce catalog performance optimization – part 4

    Recently I worked on a support case where a customer reported deadlocks and timeout exceptions on queries to a specific table – NodeEntryRelation. Yes, it was mentioned in this post. However, there is more to it. Keeping the indexes healthy definitely help to improve performance and avoid deadlocks and timeout exceptions. However it can only work to a limit, because even if the indexes are in their perfect state (the fragmentation level is 0%), the query will still take time. Looking in the query we talked about – ecf_Catalog_GetChildrenEntries – what does it do. It lists the entries which are direct children of a catalog. So normally entries belong to…

  • Catalog,  Commerce,  Episerver,  Tips

    Reindex obsolete prices in Episerver Commerce

    Recently I stumped upon this question: http://world.episerver.com/forum/developer-forum/Episerver-Commerce/Thread-Container/2017/8/event-for-price-becoming-validinvalid/ which is very interesting to me. I can see this is a real scenario – and even quite common. When a price become obsolete, you want your contents to be reindexed so the next time you query, the search result will be returned correctly. But how?

  • Catalog,  Commerce,  Episerver

    Permanently drop prices of all products

    This is an unusual post – as I usually don’t post sample code – that should be the job of the documentation. However, I jumped upon this question http://world.episerver.com/forum/developer-forum/Episerver-Commerce/Thread-Container/2017/8/global-price-increase/, and found it to be an interesting case to demo. It’s worth noting that as a customer, I’d like price drops, not the way around, so in this example, we will see how to cut prices of all products to 5%, instead of making them 5% more. Of course, it’s just simple mathematics, so you can change to the formula however you want.

  • Catalog,  Commerce,  Episerver,  Performance,  Tips,  Uncategorized

    Can Episerver Commerce support our catalog size?

    One of the questions customers usually raise during evaluation of Episerver Commerce is : “Can it support our catalog size? We have (a very big number of ) entries. Will it work?” The answer is (of course, as always): It depends! I’ve seen “big” catalogs. Some big enough in number – 1 million entries catalogs are not very uncommon, and some are even (much) bigger. Theoretically, Episerver Commerce can support up to 512 millions 1 billion of entries (!), so you can have pretty much anything in your catalog until you reach a hard technical limit. Just for comparison, Amazon.com, which is arguably the biggest eCommerce site on the world, has…

  • Catalog,  Commerce,  Episerver,  Uncategorized

    EntryContentBase, MetaObject, CatalogEntryDto, Entry: which should you use?

    It can be pretty confusing for new Commerce developers to understand how to work effectively with entries in Commerce. There are many things which represent the same concepts, however they are different and their APIs are not compatible. So which is which and what should you use? Which is which CatalogEntryDto is the DataSet to represent one or more entries (CatalogEntryDto can of course be empty). Beside the basic information like Name, Code, or MetaClassId, depends on how did you load it, a CatalogEntryDto can contain information about the assets, the associations or the variations (you can specify what to load by using CatalogEntryResponseGroup parameter. CatalogEntryDto, however, does not contain information…

  • Blogging,  Catalog,  Commerce,  Episerver,  ranting

    Catalog Search APIs are for editing only!

    If you are using Catalog Search APIs for any customer-facing features, you are doing it wrong! I have seen this problem a couple of times – the search feature on the site is “dead” – it is very slow, and the log file is usually filled with dead lock or timeout error. As it turns out, the search feature was implemented by Catalog Search APIs, which is a big no-no. To be clear, there are two builtin APIs related to searching in Episerver Commerce: the “fast” one, which can be done via SearchManager, ISearchCriteria and ISearchResults, is the SearchProvider APIs. It’s the indexed search (strictly speaking, you can make it…