[OGo-Developer] big resource hog in SoObject

[Adam Tauno Williams]

> In SOGo, most data objects implement a "lookupName:inContext:acquire:" 
> method. This method first calls its super equivalent in the case a web 
> method with the required name would exist.
> The problem is that the super method also invokes 
> "toOneRelationShipKeys", to make sure the name is available.
> It's ok for small directories but not for LDAP directories with 1000s 
> of entries. Because each time a contact card is requested, all entries 
> are scanned again, while it should be the directory controller object 
> to check whether the name is available or not...

This is a side note;  but if an LDAP query is returning 1000s of entries
you have another problem as well,  your DSA is not configured with sane
limits.  A limit of 500 objects should be more than adequate for ANY
application.  If you focus is scalability (as in SOGo) this is a serious
problem.  As an LDAP administrator I'd be pretty unhappy
[understatement] with any application that pulled thousands of objects
at a time.  Also no application should every produce as generic a filter
as to match thousands (or even hundreds) of objects as such a result set
it almost never actually valid/useful.

In OpenLDAP you can configure limits like -
limits anonymous
  size.soft=512 size.hard=1024 size.unchecked=32767
  time.soft=10 time.hard=60
limits users
  size.soft=2048 size.hard=2096 size.unchecked=32767
  time.soft=15 time.hard=60
- these are documented in man slapd.conf

If an application really does need huge results sets [indicating, IMHO,
that it is fundamentally broken] then it should use paging controls to
deal with DSA limits.

I'd recommend, at least, that your default filter be one that matches no
objects;  that way you don't pull anything unless the application takes
the time to set a real filter.

> So my request would be to remove that part between line 138 and 144 of 
> SoObject.m.
> Would that be reasonable?