Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] grouper 1.4 performance

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] grouper 1.4 performance

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Chris Hyzer <>,
  • Subject: RE: [grouper-dev] grouper 1.4 performance
  • Date: Mon, 30 Mar 2009 16:10:39 +0100

--On 30 March 2009 10:50 -0400 Chris Hyzer

This can work - the UI has a notion of paging in some areas - but should
still only kick in when we are over the configured limit for sorting. I
look forward to having sorting through the API in 1.5, but sorting is
useful in most cases so we shouldn't lose it in 1.4.

Agreed. If the display limit is 200, and the sort limit is 50, the
easiest thing is probably just to get the first page of 200. Then if
less than 200, sort it, and show 50. If greater than 200, just show 50.
Alternatively, we can get the full count, and based on that either get up
to 200 and sort, or just 50. They are probably the same performance, so
whatever is easiest to code in 1.4
I think getting the full count is probably best.

There is an issue with displaying membership lists which include
effective memberships. The UI processes the list of memberships so it
can figure out how many 'routes' for a membership there are -

No problem. I think once we get the members, we can get a list of counts
for them in one, or we can get all memberships for only the 50 members we
need in one query. We can use an "in" clause in 1 query, will be easy
and good performance. Again, if you are already working with
memberships, and that is easiest for 1.4, would be fine for performance.
I'm currently using Memberships and have a MembershipAsMap class. Safest to continue using Memberships - but how we get them isn't important.

Group.getAdmins etc could also be paged - in case anyone adds privs to a
large group rather than GrouperAll

Sure. And we can do the AccessAdapter thing where the implementor
doesn't have to implement paging, but if they do, it would be better...
again, in 1.5 if we put more info in the members table, it will be
sorted. In 1.4, it will be seemingly unordered (e.g. by subjectId)

Depending on the browse mode the UI does different things:

MyMemberships: only groups you are a member of which you can VIEW
Join groups: only groups where you have OPTIN
Manage groups: only groups where you have UPDATE or ADMIN
Explore: only groups where you have at least VIEW privilege

so you would have to join on grouper_fields - or get the ids for the
fields and do an 'in' clause - does Hibernate have a way of passing a
collection for that or do you have to build dynamic SQL - or have
separate queries?

We can easily handle this is a well-coded way. I actually picture a
generic method that uses regex where you pass it an HQL, and the security
you want on it (granted, this is the AccessAdapter doing this), and
returns the HQL of the secured query. It would just add some tables to
the from clause, and some constraints on the where clause. And it can do
"in" to pick and choose the privileges. Then that generic method would
be used by a bunch of default implementations we need (e.g. like the ones
above) so it is easy to do easy things. Or it could be in the query
options. E.g. to get all groups of a member in a certain stem, paged,
sorted (in 1.5+), and with only two privileges UPDATE and ADMIN:

List<Group> groups = member.getGroupsFromParentStem(stem,
new QueryOptions().paging(QueryPaging(1,3,true))

This would under the covers use the AccessAdapter in a smart and generic
Looks good.

> ...composite stuff...
Sounds reasonable.


(from tom)
Assuming that users don't typically want to look into the reasons why an
effective membership is there, can we optimize things so that that data
is retrieved only when the user indicates they want to know why?

Again, for 1.4 I think the least changes the better especially when I
think we can easily do this efficiently (see above). But if Gary wants
to implement this suggestion, it sounds like a good idea.
It would be nice to stick with what we have if you can come up with the count implementation

If we are paging I still think we need methods to return the membership
count so we can show text such as 'Showing 51-98 of 98 items ',
otherwise a user has no idea how many pages there might be.

My HibernateSession paging API exposes all this information. I have a
paging custom tag I could put into Grouper which has a readonly mode and
a button mode (both are shown in the attached image, one on top of the
other... page 7 is being displayed). If Gary wants to setup the
action(s) [if the paging bean is in session, I believe I just need to
pass in the page number and action from custom tag, and it will work] I
can make the custom tag work. Gary, is that something you want for 1.4
or 1.5?
Probably 1.5. If we have the total number of 'results' the current paging will work.


GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page