RE: One result call per record

2008-04-23 Thread Ron Teitelbaum 
Hi Michael,

Thanks for your response.  I'll play around with it.  The sleep time added
was to enable us to test the behavior of result.  We are calling python
through Smalltalk and we add the sleep on our end (the calling thread in
Smalltalk not python) to enable other threads to process while waiting on
responses.  I guess I assumed that the result wouldn't take more then 1 or 2
waits, and the next call would retrieve the full result set.  I didn't
expect that I needed to call result once for each record.

Thanks again for your suggestions and all your help!

Ron

> -Original Message-
> From: Michael Ströder
> 
> Ron Teitelbaum wrote:
> > While polling it appears that we have to call result for every record
> that
> > is waiting to be read.  Since we added a 250 millisecond delay between
> calls
> > larger queries are taking a really long time.
> 
> Why do you wait such a long time in an extra time.sleep() call?
> 
> >result = self.connection.result(id, True, 0)
> >time.sleep(0.25)
> 
> Hmm, I don't know very much of the inner workings of OpenLDAP's function
> ldap_result(). The behaviour also may depend on the version of OpenLDAP.
> 
> But how about fiddling around a little bit with the timeout argument for
> result()? You're blocking your while-loop with time.sleep() anyway. And
> the C wrapper module releases Python's GIL.
> 
> Something like
> 
>[..within while loop..]
>try:
>  result = l.result(msgid,True,0.25)
>except ldap.TIMEOUT:
>  continue
>else:
>  # Process result
>[..within while loop..]
> 
> I played around a little bit with the script attached on a local server
> with more than 1000 entries.
> 
> BTW: If you're after correctly dispatching results to several
> outstanding search requests you should probably use method result2()
> which also returns the message ID of the originating request:
> 
> http://python-
> ldap.sourceforge.net/doc/html/ldap.html#ldap.LDAPObject.result2
> 
> Use result3() if LDAPv3 extended controls are to be used to also receive
> controls sent by the server.
> 
> Ciao, Michael.


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Python-LDAP-dev mailing list
Python-LDAP-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: high level API for ldap object handling

2008-04-23 Thread Michael Ströder 
Olivier,

please follow-up on the python-ldap-dev (Cc:-ed) list because this is 
certainly of general interest.

Olivier Sessink wrote:
> 2008/4/23 Michael Ströder <[EMAIL PROTECTED]>:
>>  Hmm, I'm not sure I would consider this to be very high-level. If a
>> higher-level API is ever add to python-ldap it will definitely be
>> subschema-aware to map OID to NAME aliases and some more stuff and make use
>> of defaultdict stuff new in Python 2.5.
> 
> Can you explain a little what the subschema-awareness would bring for
> the python-ldap programmer? Can you give a (pseudo-code) example what
> that could look like?

It eases dealing with different attribute names and the accompanying 
OIDs. There's already something implemented in (undocumented) class 
ldap.schema.models.Entry which I heavily use in web2ldap. It does not 
implement methods for invoking the LDAP add and modify operations. It is 
still undocumented because it was never thoroughly reviewed by others 
and probably some details may need a re-design.

Ciao, Michael.

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Python-LDAP-dev mailing list
Python-LDAP-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: One result call per record

2008-04-23 Thread Michael Ströder 

Ron Teitelbaum wrote:

While polling it appears that we have to call result for every record that
is waiting to be read.  Since we added a 250 millisecond delay between calls
larger queries are taking a really long time.


Why do you wait such a long time in an extra time.sleep() call?


   result = self.connection.result(id, True, 0)
   time.sleep(0.25)


Hmm, I don't know very much of the inner workings of OpenLDAP's function 
ldap_result(). The behaviour also may depend on the version of OpenLDAP.


But how about fiddling around a little bit with the timeout argument for 
result()? You're blocking your while-loop with time.sleep() anyway. And 
the C wrapper module releases Python's GIL.


Something like

  [..within while loop..]
  try:
result = l.result(msgid,True,0.25)
  except ldap.TIMEOUT:
continue
  else:
# Process result
  [..within while loop..]

I played around a little bit with the script attached on a local server 
with more than 1000 entries.


BTW: If you're after correctly dispatching results to several 
outstanding search requests you should probably use method result2() 
which also returns the message ID of the originating request:


http://python-ldap.sourceforge.net/doc/html/ldap.html#ldap.LDAPObject.result2

Use result3() if LDAPv3 extended controls are to be used to also receive 
controls sent by the server.


Ciao, Michael.


async_result.py
Description: application/python
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
Python-LDAP-dev mailing list
Python-LDAP-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: high level API for ldap object handling

2008-04-23 Thread Michael Ströder 
Olivier,

Olivier Sessink wrote:
> 
> In my use of python-ldap I've often used a self-developed high level 
> class for ldap-object handling.
> 
> Adding a new ldap entry for example (ld is a python-ldap object):
> 
> lo = LdapOO.LdapObject()
> lo.set_dn_attribs(['cn'])
> lo.add_attribute_value('cn','test2')
> lo.set_base_dn('ou=People,o=myorg')
> lo.add_attribute_value('objectClass','inetOrgPerson')
> lo.commit_s(ld)
> 
> or modifying an existing ldap entry:
> 
> res=ld.search_s('ou=People,o=fakenet',ldap.SCOPE_SUBTREE,'(sn=surname)')
> lo = LdapOO.LdapObject(res[0][0],res[0][1])
> lo.add_attribute_value('sn','surname')
> if (not lo.has_attribute('street')):
>   lo.add_attribute_value('street','new street')
> lo.commit_s(ld)

Hmm, I'm not sure I would consider this to be very high-level. If a 
higher-level API is ever add to python-ldap it will definitely be 
subschema-aware to map OID to NAME aliases and some more stuff and make 
use of defaultdict stuff new in Python 2.5.

> since I use this class often, I was wondering if there are more people 
> that like such a high-level API, and perhaps this can be developed 
> further and added to python-ldap ?

I'd prefer you to release this as a separate package on your own web 
space since I wouldn't use it myself and therefore I'd not maintain it. 
If you do so I would be glad to link to your project page from 
python-ldap's web page so that others can find it easily.

Ciao, Michael.

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Python-LDAP-dev mailing list
Python-LDAP-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev