[OGo-Developer] big resource hog in SoObject

Helge Hess developer@opengroupware.org
Mon, 23 Jul 2007 14:47:29 +0200


On 23.07.2007, at 14:35, Wolfgang Sourdeau wrote:
> Ok. Then I could place this in SOGoObject. But it's a little  
> pornish don't you think?

I don't know what you mean by 'pornish'. SoObjects are controller  
objects and -lookupName: is the primary method to resolve URLs. Now  
how child URLs are resolved obviously depends on the controller,  
which is why its highly application specific and the method almost  
always needs to be overridden.

>> But again: I think the real flaw is that toOneRelationshipKeys is   
>> used incorrectly in the SOGo LDAP controller. It should simply  
>> not  return all IDs of the LDAP folder. Adam's post is quite valid  
>> in that  context too.
> For LDAP, that is another issue which I partly agree with... If the  
> user expects to list all the entries of an LDAP directory, then it  
> should happen...

Yes, but toOneRelationshipKeys is the wrong API for retrieving all  
items. This should be done by a proper EODataSource/ 
EOFetchSpecification based method. Which you need anyways because you  
would usually want to qualified searches ...

> But for regular use, I do plan to limit the search results. And if  
> you "connect" to an ldap addressbook from the web interface,  
> nothing will show by default (same behaviour as Thunderbird). You  
> *have* to do a search to get something.

Personally I think that it is more user friendly to run a limited  
query (say first ten records sorted by lastname) even if the user  
didn't type anything.
This is inexpensive and the user can see that the store contains items.

Further I would always limit searches to something like 50 items per  
default. If the query then hits the limit, I would show that to the  
user and then give him the option to double/triple/ignore the limit.  
Usually he will just restrict the qualifier further.
This way you avoid bothering the LDAP server unnecessarily, and the  
user will have results much faster.

Thanks,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/