When you access properties from IPublishedContent or Modelsbuilder you are not accessing the raw data stored for that property.
Instead a 'PropertyValueConverter' is run (which is specific for each type of property) to return a helpful friendly object to use in your templates.
Your MemberPicker will be storing the unique id of the picked member, but your generated Model will be running that through a PropertyValueConverter to give you a representation of the picked item in a familiar shape, eg IPublishedContent - but I don't think Member data is fully stored in the PublishedCache, so might be hitting the database to get the full information of the picked member... to construct the IPublishedContent representation and it will be doing it for every descendant document!
But in this querying context you do not need the 'Member' representation in order to compare Ids...
... So I think you could work around this using the raw stored value for the property, which I think you can access like so:
var site2 = Model.Root();
var attendeesByUser = site2.Descendants<Attendee>().Where(x => x.GetProperty("member")..GetSourceValue() == currMemberId).OrderBy(x => x.StartDate);
Member picker performance issue
Hello Everyone,
I am having performance when using member picker and checking conditions, its hitting Database and CPU goes 100 %,
in above code Member is Member picker field. When I use above code, it hits Database and CPU goes 100 %,
If I remove that condition its very quick
.Member returns Ipublishcontent then why it would go to DB to fetch content ?
Hi Nilay
When you access properties from IPublishedContent or Modelsbuilder you are not accessing the raw data stored for that property.
Instead a 'PropertyValueConverter' is run (which is specific for each type of property) to return a helpful friendly object to use in your templates.
Your MemberPicker will be storing the unique id of the picked member, but your generated Model will be running that through a PropertyValueConverter to give you a representation of the picked item in a familiar shape, eg IPublishedContent - but I don't think Member data is fully stored in the PublishedCache, so might be hitting the database to get the full information of the picked member... to construct the IPublishedContent representation and it will be doing it for every descendant document!
But in this querying context you do not need the 'Member' representation in order to compare Ids...
... So I think you could work around this using the raw stored value for the property, which I think you can access like so:
where "member" is the alias of the picker...
... I think ... !
regards
Marc
Hi Marc,
Thanks for guiding me to the right direction.
I have to tweak the code to make it work but your solution gave me righ direction
Thanks
is working on a reply...