When is it ok to use .Children and not use the index?
The reason I ask is someone recently pointed out, in the Umbraco docs there is a lot of mention of getting content from the children of IPublishedContent and not from the index.
I am assuming people will say it depends on what you are trying to implement, which I agree, although I try to stay away from .children preferring to either link data some how or get it from the index.
When I used to build Umbraco sites Umbraco =< 8 , using .Children, .Descendants always used to be a problem, for performance reasons, this might be better now, especially when people started to use ModelsBuilder.
If there is a lot of data I need to retrieve or I need to do some complex queries, I would always go to the index rather than getting children and then querying that data. Some of this also come down to the fact that I have always had content for components in a separate area of the content tree so its re-useable, that curse word ‘Sitecore’ and thus you cannot just do .Children.
This is a great question. My methodology has changed over time. I now avoid using the examine index whenever possible. We have had too many issues with locked examine index files breaking site search. I now only use examine search for user-initiated searches, or when I need to use examine index features, like fuzzy search.
The biggest takeaway is that if you are accessing the published content children or descendants, you are not searching the SQL database - you are parsing the content cache. The published content is cached, and you are parsing the cache. You should still cache expensive queries that do a lot of processing on your own, but generally I haven’t needed to implement my own cache unless the performance is noticeably slow. The published content cache performance is pretty good.
So yes, still avoid descendant queries where possible, you should “walk” down the content tree by getting specific children nodes of a child node, etc. to get the specific nodes you want, ex.
var blogIndexNodes = ctx.ContentAtRoot()?.FirstOrDefault(x => x.ContentType.Alias == "home")?.ChildrenOfType("blogIndex");
but it probably isn’t as big of an issue as it used to be.
Also I believe some improvements to node caching are on the way to umbraco, so you can customize what the rules are for caching nodes by default.
An interesting follow up note, the examine locking issues of the past may have been largely fixed last year in Examine 3.3.0, though I cannot verify it:
Yea I have had a ton of locking issues in the past especially with Azure, these have got much better / fixed. I still found them when I was using Umbraco Cloud a while ago, but that might have been fixed now as well
