Hello all
I am currently rewriting the uHangout website and want to ensure I am querying for nodes in the most efficient manner.
Firstly lets take two examples, I am curious do they do the same thing under the hood and just use different syntax or if one is different than the other and effectively more peformant than the other.
This example code is a WebAPI class that inherits from UmbracoApiController, so Umbraco Services, UmbracoContext & UmbracoHelper are all available to me.
//Get me all the nodes of doctype 'Video'
var videos = Umbraco.TypedContentAtXPath("//Video");
var videos2 = UmbracoContext.ContentCache.GetByXPath("//Video");
//Find a video by a YouTube ID on a property
var findVideo = videos.SingleOrDefault(x => x.GetPropertyValue<string>("youTubeVideoId") == videoIdToFind);
So come on you clever lot tell me which one is the best one to use and if there is any difference between the two at all?
Also I am curious to know if there is a nicer syntax way similar in the ContentService (I know not designed for read but CRUD) there is a method of Services.ContentService.GetContentOfContentType() which is what I am replicating with the the XPath example above and then applying Lambada Linq expressions to filter, order & take what I need.
I've used both before and too be honest I don't know the real difference either. Both also have methods to return content based on an id. The only difference I know of is that both are available at different parts of the code.
Umbraco.TypedContentAtXPath --> I usually use in views or controllers. contentRequest.RoutingContext.UmbracoContext.ContentCache.GetByXPath or umbracoContext.ContentCache.GetByXPath --> I use in content finders or url providers.
Have you already looked at the source code? Maybe both go down to the same method under the hood.
There is no difference. If you look in the Umbraco source and trace back the method calls, Umbraco.TypedContentAtXPath ultimately calls UmbracoContext.ContentCache.GetByXPath. Umbraco.TypedContentAtXPath then is just on the UmbracoHelper class for convenience / a nicer way to get to it.
As far as I can tell through a source-code-deep-dive they both eventually end up in PublishedContentCache.GetByXPath(), so performance should be exactly the same. I guess your desired way there depends on your current context. When you have both available, just pick one I guess :)
If you want to bypass the XPath route, you should probably look to Examine.
Note that the TypedSearch method is on the UmbracoHelper instance.
I'm not sure you'll find a similar syntax as the one from the ContentService, as least not at the moment.
But Shannon would know more about that than me.
Hi Mads,
I know my colleague Mr Examine aka Ismail Mayat would prefer me to build everything using Examine & Lucene :-P
So many different ways to query, I always get overwhelmed and I just want to make the new uHangout site best practise for me to learn anything new along the way. As I am always so resilient to use Examine, maybe its time I should.
I didn't know that you and Ismail are colleagues, that makes using Examine even more obvious :)
But indeed, the options are many, too many some would say. I guess that's the consequence of putting in so many context based helper methods, because, most of the time, they all end up doing the same thing anyways :)
Querying - UmbracoContext.ContentCache.GetByXPath OR Umbraco.TypedContentAtXPath ?
Hello all
I am currently rewriting the uHangout website and want to ensure I am querying for nodes in the most efficient manner.
Firstly lets take two examples, I am curious do they do the same thing under the hood and just use different syntax or if one is different than the other and effectively more peformant than the other.
This example code is a WebAPI class that inherits from UmbracoApiController, so Umbraco Services, UmbracoContext & UmbracoHelper are all available to me.
So come on you clever lot tell me which one is the best one to use and if there is any difference between the two at all?
Also I am curious to know if there is a nicer syntax way similar in the ContentService (I know not designed for read but CRUD) there is a method of Services.ContentService.GetContentOfContentType() which is what I am replicating with the the XPath example above and then applying Lambada Linq expressions to filter, order & take what I need.
Cheers,
Warren
Hi Warren,
I've used both before and too be honest I don't know the real difference either. Both also have methods to return content based on an id. The only difference I know of is that both are available at different parts of the code.
Umbraco.TypedContentAtXPath --> I usually use in views or controllers.
contentRequest.RoutingContext.UmbracoContext.ContentCache.GetByXPath or umbracoContext.ContentCache.GetByXPath --> I use in content finders or url providers.
Have you already looked at the source code? Maybe both go down to the same method under the hood.
Jeroen
Hey Warren,
There is no difference. If you look in the Umbraco source and trace back the method calls, Umbraco.TypedContentAtXPath ultimately calls UmbracoContext.ContentCache.GetByXPath. Umbraco.TypedContentAtXPath then is just on the UmbracoHelper class for convenience / a nicer way to get to it.
Matt
Hi Warren
As far as I can tell through a source-code-deep-dive they both eventually end up in
PublishedContentCache.GetByXPath(), so performance should be exactly the same. I guess your desired way there depends on your current context. When you have both available, just pick one I guess :)If you want to bypass the XPath route, you should probably look to Examine.
Note that the TypedSearch method is on the UmbracoHelper instance.
I'm not sure you'll find a similar syntax as the one from the ContentService, as least not at the moment.
But Shannon would know more about that than me.
- Cheers
Hi Mads,
I know my colleague Mr Examine aka Ismail Mayat would prefer me to build everything using Examine & Lucene :-P
So many different ways to query, I always get overwhelmed and I just want to make the new uHangout site best practise for me to learn anything new along the way. As I am always so resilient to use Examine, maybe its time I should.
Cheers all
Warren
Hi Warren
I didn't know that you and Ismail are colleagues, that makes using Examine even more obvious :)
But indeed, the options are many, too many some would say. I guess that's the consequence of putting in so many context based helper methods, because, most of the time, they all end up doing the same thing anyways :)
Cheers
is working on a reply...