I can't edit the above post, but just to let you know, I need the IDs of the members (as these are used to reference something), and Roles.GetUsersInRole() only brings back a string array?
You're right about GetUsersInRole() - that only returns a string-array of the member's login-names.
The following code snippet uses the Umbraco Member API directly:
var list = new List<int>();
var memberGroup = MemberGroup.GetByName("Member Group Name");
if (memberGroup != null)
{
foreach (Member member in memberGroup.GetMembers())
{
list.Add(member.Id);
}
}
Ahhh... Thank you! I never thought of doing it that way round! That looks like it will work perfectly for what I am trying to do!
I have read around the forum and it says using the Member API with a lot of members may become slow and make alot of DB calls. Will that be the case with this method, or was that on an older version of Umbraco?
Forget my last code snippet... here's a better one! ;-)
var list = MemberGroup.GetByName("Member Group Name").GetMembersAsIds();
Just found the "GetMembersAsIds()" method when I was looking at the core code!
That will do 2 SQL calls - one for GetByName and then another for GetMembersAsIds. If you knew the Id of the MemberGroup, then you could cut it down to 1 SQL... but really, it shouldn't be an issue! :-D
Do you know how many calls should the first method do to the DB as I may need the member names, so might have to use that way, or is it much of a muchness?
The UmbracoRoleProvider's "GetUsersInRole" method makes the following SQL calls... 1 to get the MemberGroup (by name), another to get a list of all the member Ids ... then its 1 SQL call per Member node.
Once you have the Member node, there'll be 1 SQL call per its core properties (LoginName, Password, Email and Text) ... once you retrieve the data once, its stored in memory for future re-use. So the initial hit will make a lot of SQL calls - but after that, not much.
Personally I'd say don't worry about it... use the API as you need it! Then later on if you find it to be a real bottleneck - then refactor your code accordingly. Don't spend too much time trying to squeeze performance out of small code.
Getting all Members in a Membergroup.
Hi
I am using umbraco v 4.0.3 and I want to get a list of all members in a particular membergroup.
This is in c#!
What's the best way of doing this?
I have tried using the Umbraco.buisnesslogic.member.Member and there doesn't seem to a function to do this?
Should I be using the roles provider and going: Roles.GetUsersInRole()?
Can someone tell me which is the best way of doing this?
Bex
I can't edit the above post, but just to let you know, I need the IDs of the members (as these are used to reference something), and Roles.GetUsersInRole() only brings back a string array?
Hi Bex,
You're right about GetUsersInRole() - that only returns a string-array of the member's login-names.
The following code snippet uses the Umbraco Member API directly:
Cheers, Lee.
Hi Lee!
Ahhh... Thank you! I never thought of doing it that way round!
That looks like it will work perfectly for what I am trying to do!
I have read around the forum and it says using the Member API with a lot of members may become slow and make alot of DB calls.
Will that be the case with this method, or was that on an older version of Umbraco?
Bex
Hi Bex,
Forget my last code snippet... here's a better one! ;-)
Just found the "GetMembersAsIds()" method when I was looking at the core code!
That will do 2 SQL calls - one for GetByName and then another for GetMembersAsIds. If you knew the Id of the MemberGroup, then you could cut it down to 1 SQL... but really, it shouldn't be an issue! :-D
Cheers, Lee.
Thanks Lee.
Do you know how many calls should the first method do to the DB as I may need the member names, so might have to use that way, or is it much of a muchness?
Bex
The UmbracoRoleProvider's "GetUsersInRole" method makes the following SQL calls... 1 to get the MemberGroup (by name), another to get a list of all the member Ids ... then its 1 SQL call per Member node.
Once you have the Member node, there'll be 1 SQL call per its core properties (LoginName, Password, Email and Text) ... once you retrieve the data once, its stored in memory for future re-use. So the initial hit will make a lot of SQL calls - but after that, not much.
Personally I'd say don't worry about it... use the API as you need it! Then later on if you find it to be a real bottleneck - then refactor your code accordingly. Don't spend too much time trying to squeeze performance out of small code.
Cheers, Lee.
Hi,
When you don't query more than 500 members use the API. Otherwise a custom select on the database would make more sense.
Cheers,
Richard
is working on a reply...