[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:
>>> 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

Ack, pushed to master.

I do wonder if the pre/post callbacks should be moved up a level so they 
are part of the general framework but we can argue that later.

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/20090615/085972f3/attachment.bin>