How to find the intersection between groups?

[Karola Schaeuble]

To find out which users are in group A as well as in group B I can resolve the members of A and and see if they are members of B. This is all well until we have groups with thousands of users then the system nearly grinds to a halt.

So is there already a convenient way build into the user/group management to get all the users who are in group A AND B?

One thing that could help here would be to know which of the groups is the smaller one. Though it would still be bad if I have two very large groups.

Any help on this is appreciated.

EDIT:

Okay I found the query alternative, as it was mentioned here: https://answers.atlassian.com/questions/67/how-do-i-get-the-list-of-all-users</p<>>

I can build a query like this one:

PartialEntityQueryWithRestriction<User> query = QueryBuilder
                .queryFor(User.class, EntityDescriptor.user()).with(
                    Combine.allOf(
                        Restriction.on(GroupTermKeys.NAME).exactlyMatching(group1.getName()),
                        Restriction.on(GroupTermKeys.NAME).exactlyMatching(group2.getName())));
 

The only problem is, that I now need an EntityQuery to do the search with Crowd. I could add a returningAtMost(int) at the end but what if I really want all matching users? Do I have to repeat the query until users returned are less than the int? Does this still perform? And what would be a feasable limit?

[Andrew Ardill · Accepted solution]

Apart from using a different query, which I am not aware of, this is a place where an optimized algorithm can help a lot.

It sounds like you are looping through all the users in group A, and comparing each one with all the users in group B. If there are 'a' users in group A and 'b' users in group B this means you have a*b comparisons to do, which is quite large if you have a large number of users in either of the groups.

Instead of doing this, a simple box-sort style counting algorithm can be used. You first create a HashMap<User, Integer> userCount. Traverse the first group A, and increase the count for each useryou find (if they are not in the map, add them with value 1, otherwise increase the value by 1). Then, traverse the second list B and increase the count again. Finally, traverse the EntrySet of the map, any entry that has a count of two is in the intersection.

This method can be extended to finding the intersect of many groups, by repeating the process for each group and looking for the count to be the same as the number of groups you have.

For the case of only two groups you can increase performance by, when running through group B, simply checking to see which users are already in the hashmap.

The performance boost you will notice from this method is due to the quick insertion and lookup time that a hashmap provides. Looking up and inserting an entry in a hash map takes constant time, so with the most optimal method for the 2 group case finding the intersection of group A and B will take around a+b operations.

[Karola Schaeuble]

That is an interessting idea. It implies that the bottleneck mainly lies in looking up each member of A in B and not in getting all the members and iterating them. Because in your solution you would iterate through both groups and not just one.

But you are right in the plugin it would come down to finding the intersect of several groups.

[Andrew Ardill]

Retreiving a list of users in a group is a simple problem, and should not cause performance issues. The bottleneck is in the algorithm for fidning the intersection.

The naive way of doing this goes through every user and sees if they are in every group, which takes a lot of work. When you have more than 2 groups it quickly becomes infeasible to use this method.

The smarter way goes through each group once, and counts how many times each user is seen.

[Karola Schaeuble]

Yeah I thought so, just wanted to make sure.

I will definetely put that into my toolbox for future use. For now I have to somehow convince our supplier to change their code accordingly.

[yzwangxinhai]

Magnetite ore dressing technology is mature, widely used in each big magnetite concentrator.Magnetic separation process flow of stage grinding phase, the grade of iron ore 26.23%, concentrate iron grade up to 67. 15%, iron recovery was 81. 08%.Aoshan iron ore concentrator choose dry tail, advance stage grinding, stage classification process, the iron ore grade 23. 54%, the iron concentrate grade is 64. 08%, iron recovery was 73.73%.Chenchao iron refinery concentrator of existing ore dressing process adopts the three sections of a closed road, two pieces of closed-circuit grinding, dry separation behind the tail stage grinding, stage, in addition.Iron ore grade is 30. 36%, the iron concentrate grade 66. 51%, the iron recovery rate was 83. 26%.
 
In the form of magnetite in the ore of iron containing Yu Quantie content of 85%, the biggest said magnetite ore.The core of the magnetite ore dressing technology is weak magnetic separation, and other processing technology include: undressed ore primary left tail, concentrate the float to choose desulfurization, desilication, etc.
 
The characteristics of the process is: in the coarse crushing magnetite dressing or broken after coarse select operation, using magnetic pulley advance tail, selected a part of the waste rock, reduce the ore into the ground, reduce the processing cost;Stage grinding stage, reduce the grinding energy consumption;Concentrate reverse flotation desulfurization or desilication, improved the quality of iron concentrate.

[Karola Schaeuble]

No I want to do it in a plugin so the Java API is the way to go. i don't want a plugin to access the DB directly.

[Colin Goudie]

Are you after a way to do this via Confluence Java API or is SQL ok?

[Karola Schaeuble]

The UserAccessor.findUsers(Query) would be cool, but I can't get it to work as the UsersInGroupTwoTermQuery does not exist anymore. Is there an alternative for this?