Grouper Developers Forum

[Tom Zeller <>]

Picking this thread back up...

>> > Then maybe we need to return all subjects, and not just the id, right?  
>> > Or do you want two strings for each subject?  Id and netId (identifier)?
>> > Btw, to return all subject info for all subjects with 540k of them takes 
>> > a lot of memory...
>>
>> So, how about Iterator<Subject> getAllSubjects() ?
>
> You could do that in ldap?

Well, not really. There are paging controls which are supported in
various ways, but the implementation of Iterator probably would be
Set.iterator().

>> I was just wanting a single Set<String> of either id or identifier so
>> I could then query for each Subject in turn.
>
> Got it.  Yeah, then a list of subjectIds is probably the best.  For the 
> iterator it would need to be a callback so the statement could be closed 
> and the connection returned to pool.  E.g.
>
> source.allSubjectsProcessor(new ProcessorCallback() {
>  public void process(int index, Subject subject) {
>    //do some logic to the ldap...
>  }
>
> });
>
> So like I said, the list of ids is probably better and easier for source 
> implementers to do...  a little while ago I added 
> Source.getSubjectsByIds(Collection<String>) which could speed things up 
> here perhaps...
>
> Chris

So, I'm tentatively merging shibboleth DataConnectors and grouper
subject api Sources. The shibboleth attribute resolver requires
DataConnectors, but for provisioning I'm looking for Set<String>
getAllIdentifiers so I can provision all groups, stems, members, etc.

I can extend the grouper DataConnectors to provide getAllIdentifiers()
for now. Perhaps eventually, sources for provisioning will be a
combination of DataConnector and Source. I'll just do this for
ldappc-ng, and if we get around to modifying the subject api later,
that's fine.

TomZ