I have a list of members I need to filter by name and apply pagination to.
I get all the members as follows:
List<int> memberIds = null;
UmbracoDatabase db = ApplicationContext.Current.DatabaseContext.Database;
memberIds = db.Query<int>("SELECT id FROM umbracoNode WHERE nodeObjectType='39EB0F98-B348-42A1-8662-E7EB18487560'").ToList();
After that I get the full Ipublished member.
List<ExtendedMember> extendedMembers = new List<ExtendedMember>();
foreach (int memberId in memberIds)
{
IPublishedContent currentPublishedMember = memberShipHelper.GetById(memberId);
ExtendedMember extendedMember = new ExtendedMember(currentPublishedMember);
//MemberEmail is alleen Dynamisch beschikbaar
extendedMember.Email = (extendedMember.GetProperty("Email").Value != null ? extendedMember.GetProperty("Email").Value.ToString() : "");
extendedMembers.Add(extendedMember);
}
The problem is that this takes way to long (about 8 sec) and I get a lot of stuff I don't need.
I need the member:
Firstname
Prefix
Last name
Phonenumber
profile image
Seems a bit silly to get the full IPublishedMember for this.
What would be the best approach to make this perform better?
I could cache the result, but when and how and how about filtering?
I could make a custom database table and fill it with the content I
need and query the database with the correct filters?
Make a new DB table.
Put a generate method wich we can call in a dashboard later on.
On memberservice.Save we look if the member exists in the table, delete the entry en put the new member in there.
On memberservice.Deleting we remove the entry all toghether
Now we have a table we can query vor filtering and paging. This gives us the speed we want.
Haha sorry, I actually want to make you extra excited. Check out the existing InternalMemberIndexer that already exists and will be kept up-to-date for you. You can query it for the data you need.
Update: Something like this should help:
var searcher = ExamineManager.Instance.SearchProviderCollection["InternalMemberSearcher"];
var result = searcher.Search(query, useWildcards);
I'll look into it and we have to decide if we keep our solution or rebuild to this solution...
Can you predict what will happen if 10 members update there profile at the same time and we re-index on every save event? Now we only update the entry of the editing member.
We are both talking about listing and filtering members on the site, not in the umbraco backoffice right?
I thought that was the separation between internal and external indexers.
Ok, we had a play with the index this morning and after that had a discussion on how to proceed. We decided to remove our solution and use the indexer instead. Its blazing fast.
We are also going to use it to list all members becouse it's faster than querying the umbracoNode table and getting the I published content for the overview. We can use the examine fields instead.
display and filter a lot of members (+/- 500)
Hi,
I have a list of members I need to filter by name and apply pagination to.
I get all the members as follows:
After that I get the full Ipublished member.
The problem is that this takes way to long (about 8 sec) and I get a lot of stuff I don't need.
I need the member:
Seems a bit silly to get the full IPublishedMember for this.
What would be the best approach to make this perform better?
Thanks again,
Frans
Ok,
What we ended up doing was:
Make a new DB table. Put a generate method wich we can call in a dashboard later on. On memberservice.Save we look if the member exists in the table, delete the entry en put the new member in there. On memberservice.Deleting we remove the entry all toghether
Now we have a table we can query vor filtering and paging. This gives us the speed we want.
Might be a lot easier and more consistent to use the existing Examine index for this? :-)
Every time you take my excitement away by pointing to a better solution :-P At least this was the faster solution at the moment...
We use examine for the site search. The members have a separate search and filter function.
Is it possible to have multiple external indexes side-by-side or should I use one index and look for different keywords?
Isn't there a issue with about 500 members triggering the examine re-index on every save?
Haha sorry, I actually want to make you extra excited. Check out the existing
InternalMemberIndexer
that already exists and will be kept up-to-date for you. You can query it for the data you need.Update: Something like this should help:
Docs are here: https://our.umbraco.org/documentation/reference/searching/examine/examine-manager
How could I have missed that... :o
I'll look into it and we have to decide if we keep our solution or rebuild to this solution...
Can you predict what will happen if 10 members update there profile at the same time and we re-index on every save event? Now we only update the entry of the editing member.
Don't re-index. It is wired up to re-index itself every time a member gets saved (you don't want to double-re-index). :-)
One final question and just to be sure..
We are both talking about listing and filtering members on the site, not in the umbraco backoffice right? I thought that was the separation between internal and external indexers.
Only by convention. You can use any Examine index for any purpose.
Ok, we had a play with the index this morning and after that had a discussion on how to proceed. We decided to remove our solution and use the indexer instead. Its blazing fast.
We are also going to use it to list all members becouse it's faster than querying the umbracoNode table and getting the I published content for the overview. We can use the examine fields instead.
Thanks!!
is working on a reply...