Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

--On 25 February 2009 09:39 -0500 Chris Hyzer 
<>
 wrote:

> > 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,
I was trying to avoid the extra query given the size of the membership 
table though indexes may make it quick enough
> or only select with
> limit...  hibernate has nice paging built in
We could configure a maximum membership size for the UI - we'd want to show 
when it had been reached and possibly
> > 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
That was the idea - it is up to the Subject implementation to specify the 
sort string. It could be changed and the new values would ripple through. 
We could extend JDBC and JNDI source adapter configuration to allow one or 
more attributes to be used as the sort string.
> > 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.
LDAP isn't my strong point. I see the point about searching groups and 
subjects as one index
> > 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...
Limits are configurable and may depend on the bind account. Tom B. has 
always been against a 'slurp' method, but it could be optional.
> Regards,
> Chris



----------------------
GW Brown, Information Systems and Computing