[OGo-Developer] big resource hog in SoObject

[Helge Hess]

On 20.07.2007, at 22:05, Wolfgang Sourdeau wrote:
> 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...
>
> So my request would be to remove that part between line 138 and 144  
> of SoObject.m.
>
> Would that be reasonable?

I have no strong opinion on that, but the impression that the current  
behaviour is quite a good (convenient) generic default behaviour  
because it allows you to drop in EO objects w/o additional work. The  
toOneRelationshipKeys thing is for EOModel/CoreData applications, and  
you rarely have 10+ toOne relationships.

Besides that I also have the impression that toOneRelationshipKeys  
should never ever return 1000+ objects?! That is, the default  
implementation of that method is obviously a no go for your LDAP  
controller? I suppose your controller might want to expose the  
children as a single toManyRelationshipKey. Or probably not at all.
I don't know why SOGo would ever call toOneRelationshipKeys on an  
object (outside -lookupName). WebDAV has its own EOFetchSpecification  
based methods which can be overridden for performance (see ZideStore)  
and the web interface can always properly qualify searches in the  
proper action.

Summary: I would be interested on ZNeKs opinion on that. We can drop  
it, but I *think* that your issue is at a different place (the way  
your object maps to KVC).

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