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:

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);
    }
}

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! ;-)

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

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...