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

[Pavel Zuna]

Rob Crittenden wrote:
> 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

I did some re-basing and here's patch 0011 with truncated search results support.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-new-set-of-base-classes-for-plugins-using-LDAP.patch
Type: application/mbox
Size: 12707 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20090615/34877f36/attachment.mbox>