Grouper Developers Forum

[Chris Hyzer <>]

> If there were an immediate membership count on the group object updated
> when  memberships are changed, the UI and other clients could adapt
> their
> behaviour and try not to do 'silly' things like list 60K of members.

Or we could just do a count(*) before selecting all, or only select with 
limit...  hibernate has nice paging built in

> Sounds like the sort of thing Signet does. Could get quite big. What
> about
> having an extra Subject method - getSortString? The value would be
> stashed
> in the Member table - along with the time it was last verified (then
> you
> can configure the value to be verified and updated if the time of
> retrieval
> is more than, say, an hour since the last check)

As long as each query always sorts by the same string, Im good with it

> I like the idea of indexing grouper attributes this way and adding to
> the
> current query filters. Not sure about Subjects. My take would be that
> Sources ought to be able to do the searching, sorting and paging you
> need.
> We can extend the Subject API to take advantage of such features, or
> sources can emulate them, but we shouldn't have Grouper specific stuff.

The problem is we want one list based on many sources.  Also, I think LDAP 
doesn’t have good support for a sorting and paged query, but maybe I am wrong.

> When xml-importing, it might be nice to have 
> Source.getAllSubjectsAndCache() and store Subjects in 
> memory to avoid 'many' lookups. Retrieving Subjects using a configurable 
> size, e.g. getSubjects(Set 
> members, int batchsize), might also be helpful.

I think a method in a source to get all would do the trick.  However, can 
this be done easily from LDAP?   I thought there were limits and such... 

Regards,
Chris