Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] subject attribute cache?

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] subject attribute cache?


Chronological Thread 
  • From: Tom Zeller <>
  • To: Chris Hyzer <>
  • Cc: "GW Brown, Information Systems and Computing" <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] subject attribute cache?
  • Date: Wed, 25 Feb 2009 09:06:22 -0600
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=tR7lZYsASa8KVzinHxb62G4mTCm/gqo66Is9QXosv08VTUWOtOlC2vMrfZdm0jhRx0 NZ6JdZg+zrwInONkUgZRZTdmnC1/gnthdMizEhydzZV+/DpRM7XYp2mJ2JsoQRXTSiPS d1mR4cy+ao26AekiwT/OdmtJV4TWzKM28ZInM=

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...

Sure, LDAP searches and servers have time limits and limits on the number of objects looked-through, which is why I suggested 'optional' methods to Source, since these limits are implementation and site (!) specific. For example, our Active Directory LDAP interface is easily slurped by using built-in JNDI paging. Our RedHat directory server, however, does not support paging. It seems the LDAPSource would need appropriate configuration parameters - doable.




Archive powered by MHonArc 2.6.16.

Top of Page