When a content that has an AutoroutePart is created/updated/published, the AutoroutePartHandler runs its processes to check whether the DispayAlias should be updated. We found a possible way to prevent this from hitting the database in some condition.
The idea is, we already have a "record" of Published DisplayAliases in AliasService, so we can hit that first, and if we found a matching alias, and that alias maps to the content's display route, we don't need to hit the database to figure out whether we need to do any processing.
So, on Updated and Published events for a ContentItem that is already Published and whose DisplayAlias did not change, we are set.
(In some of our applications this scenario is actually the most common.)
A PR is coming soon.
When a content that has an AutoroutePart is created/updated/published, the AutoroutePartHandler runs its processes to check whether the DispayAlias should be updated. We found a possible way to prevent this from hitting the database in some condition.
The idea is, we already have a "record" of Published DisplayAliases in AliasService, so we can hit that first, and if we found a matching alias, and that alias maps to the content's display route, we don't need to hit the database to figure out whether we need to do any processing.
So, on Updated and Published events for a ContentItem that is already Published and whose DisplayAlias did not change, we are set.
(In some of our applications this scenario is actually the most common.)
A PR is coming soon.