[Freeipa-devel] Re: [PATCHES] Add new set of base classes for plugins using LDAP.

[Rob Crittenden]

Pavel Zuna wrote:
> Rob Crittenden wrote:
>> Pavel Zuna wrote:
>>> I rewritten the patches I posted last week according to the feedback 
>>> I got.
>>>
>>> The changes are:
>>> - all the functionality specific to LDAP plugin base classes has been 
>>> removed from Object and crud base classes.
>>> - there is now 2 types of callbacks: pre_callbacks (called before 
>>> passing data to python-ldap throught the LDAP backend) and 
>>> post_callbacks (called after getting output from python-ldap)
>>> - some bug fixes
>>>
>>> Patch 0006: Modify PluginProxy to use __public__ defined in derived 
>>> classes instead of base classes.
>>
>> ack
>>
>>>
>>> Patch 0007: Add 'parent_key' kwarg in Param class.
>>
>> ack, still not super happy with the variable name but since I can't 
>> come up with anything better we'll stick with it :-)
>>
>>>
>>> Patch 0008: Make get_dn parameter list more generic. Fix Attribute 
>>> name regex.
>>>
>>> The old name regex made it impossible to have Attribute instances 
>>> with names composed of more than two words separated by underscores.
>>
>> ack
>>
>>>
>>> Patch 0009: Generate crud.Search arguments with get_args.
>>>
>>> (This might not be required, but I wanted to make sure arguments are 
>>> generated properly in subclasses.)
>>
>> ack
>>
>>>
>>> (Patch 0010 is in a separate e-mail at Martin's request.)
>>>
>>> Patch 0011: Add new set of base classes for plugins using LDAP.
>>
>> nack. The reason that 2 values are returned in a list via the search 
>> in the current backend (and v1) is so you can tell whether a search 
>> failed because it exceeded either the size or time limits. We called 
>> this a "truncated" search. We return as much as we can though. I think 
>> we should retain this capability, even if we do it slightly differently.
> I played a bit with python-ldap and the only way to do this is to make 
> an asynchronous search, then pull the entries one by one. I don't know 
> what the common size/time limits are on DS, but pulling thousands of 
> entries one by one didn't seem like a good idea. Although maybe it's not 
> such a big deal as I think.

Well, no guarantee that they will be returned one by one but yes, you 
need to continue a looping read until all the results are returned. You 
wouldn't end up pulling thousands of records unless the admin set the 
limits that high.

But it does provide a nice degraded operation so that rather than 
getting a cryptic error message about limits being exceeded they get 
something to look at.

> At this point, if some limit is exceeded, an exception is raised and the 
> user needs to narrow down his search criteria. If we want to retain the 
> 'truncated' search capability, I'll implement it, but it will require 
> small changes in a lot of places. If this is the only complain about the 
> new bases classes, I think they should be pushed - the problem is 
> actually in the LDAP backend itself.
> 

It is actually fairly fundamental because it changes the data coming 
back out of the find commands. Rather than a list of entries it will be 
a tuple with the first value being the number of entries returned and 
the list of entries.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20090610/2f963a33/attachment.bin>