LDAP ORM
Hi all, The current Python LDAP interface is a bit low level for my liking, so I've started work on an LDAP ORM[1]. Currently there's very little RM going on, but I have got a nice Python object representing an LDAP object with attribute access and deletion, no adding or saving to the ldap server just yet. ldap.schema is really quite handy. Which brings me to my next point - could someone update the API docs on the website? They're 3.5 years out of date, and so missing things like ldap.schema and cidict. Here's a patch for cidict to implement __contains__, which makes foo in somecidict work right: --- cidict.py~ 2003-08-25 00:28:12.0 +0800 +++ cidict.py 2007-10-22 20:16:54.0 +0800 @@ -43,6 +43,9 @@ def has_key(self,key): return UserDict.has_key(self,lower(key)) + def __contains__(self,key): +return UserDict.has_key(self,lower(key)) + def get(self,key,failobj=None): try: return self[key] Anyway, I'd appreciate any comments or suggestions (including for a new name) on LDAP ORM. I have a vague goal of being able to use LDAP as an ORM for Django or whatever other web framework tickles your fancy. [1] http://trs80.ucc.asn.au/ldaporm.py James Andrewartha - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: LDAP ORM
James Andrewartha wrote: > > --- cidict.py~ 2003-08-25 00:28:12.0 +0800 > +++ cidict.py 2007-10-22 20:16:54.0 +0800 > @@ -43,6 +43,9 @@ >def has_key(self,key): > return UserDict.has_key(self,lower(key)) > > + def __contains__(self,key): > +return UserDict.has_key(self,lower(key)) > + >def get(self,key,failobj=None): > try: >return self[key] I'd prefer if it's ok for you: def __contains__(self,key): return self.has_key(self,key) If you're using ldap.schema you might want to look into using class ldap.schema.models.Entry instead of simply ldap.cidict.cidict because you don't have to care about attribute description aliases and mapping them to OIDs. Ciao, Michael. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: LDAP ORM
On Mon, 2007-10-22 at 15:05 +0200, Michael Ströder wrote: > James Andrewartha wrote: > > > > --- cidict.py~ 2003-08-25 00:28:12.0 +0800 > > +++ cidict.py 2007-10-22 20:16:54.0 +0800 > > @@ -43,6 +43,9 @@ > >def has_key(self,key): > > return UserDict.has_key(self,lower(key)) > > > > + def __contains__(self,key): > > +return UserDict.has_key(self,lower(key)) > > + > >def get(self,key,failobj=None): > > try: > >return self[key] > > I'd prefer if it's ok for you: > > def __contains__(self,key): > return self.has_key(self,key) Sure, I was just copying has_key(). > If you're using ldap.schema you might want to look into using class > ldap.schema.models.Entry instead of simply ldap.cidict.cidict because > you don't have to care about attribute description aliases and mapping > them to OIDs. I'm happy with the setup I've got now, but if I ever need to deal with attribute OIDs then I'll look into it. James Andrewartha - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: LDAP ORM
James Andrewartha wrote: > On Mon, 2007-10-22 at 15:05 +0200, Michael Ströder wrote: > >> If you're using ldap.schema you might want to look into using class >> ldap.schema.models.Entry instead of simply ldap.cidict.cidict because >> you don't have to care about attribute description aliases and mapping >> them to OIDs. > > I'm happy with the setup I've got now, but if I ever need to deal with > attribute OIDs then I'll look into it. Well, it's not a matter of you personally need to deal with it. There might be the case that an attribute type or object class does not have NAME assigned at all. Also think about language sub-types and transfer type ;binary separated by ; from the name. And dashes (-) are allowed in AttributeTypeDescription. You really should dive into RFC 4512. Ciao, Michael. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: LDAP ORM
On Mon, 2007-10-22 at 07:12 -0700, Anil Jangity wrote: > I was toying with the idea of doing just this thing a few days ago. > It'll be nice if it also handles all the modifications of an entry > with ease. (changing rdn when the attributes change etc...) > > Let me know how I can help. :) Well, have a look and see if what I've got so far seems sane, or if it needs more comments/explanation etc. > My main dev environment is pylons. Site doesn't work. > > ~ $ wget http://trs80.ucc.asn.au/ldaporm.py > --07:11:50-- http://trs80.ucc.asn.au/ldaporm.py >=> `ldaporm.py' > Resolving trs80.ucc.asn.au... 130.95.13.9 > Connecting to trs80.ucc.asn.au[130.95.13.9]:80... connected. > HTTP request sent, awaiting response... 500 Internal Server Error > 07:11:51 ERROR 500: Internal Server Error. Oops, it wasn't supposed to be interpreted by the webserver. Try http://trs80.ucc.asn.au/ldaporm.pys instead. James Andrewartha - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: LDAP ORM
On Mon, 2007-10-22 at 16:13 +0200, Michael Ströder wrote: > James Andrewartha wrote: > > On Mon, 2007-10-22 at 15:05 +0200, Michael Ströder wrote: > >> If you're using ldap.schema you might want to look into using class > >> ldap.schema.models.Entry instead of simply ldap.cidict.cidict because > >> you don't have to care about attribute description aliases and mapping > >> them to OIDs. > > > > I'm happy with the setup I've got now, but if I ever need to deal with > > attribute OIDs then I'll look into it. > > Well, it's not a matter of you personally need to deal with it. There > might be the case that an attribute type or object class does not have > NAME assigned at all. Also think about language sub-types and transfer > type ;binary separated by ; from the name. And dashes (-) are allowed in > AttributeTypeDescription. You really should dive into RFC 4512. Thanks for the pointer. I've updated the code to map _ in attribute names to -. Attributes without a short name are impossible to wrap - I'm not expecting clients of this library to know OIDs. Attributes with options are accessible via obj.['cn;lang-en'] (as are normal attributes). There should probably be some functions to ask for a specific language, RFC 3866 will guide me there. James Andrewartha - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: LDAP ORM
James Andrewartha wrote: > > Thanks for the pointer. I've updated the code to map _ in attribute > names to -. Attributes without a short name are impossible to wrap - I'm > not expecting clients of this library to know OIDs. If you don't support schema elements without NAME you're not LDAPv3 compliant. I saw schema elements without NAME and my web2ldap choked on this in the beginning. In this case the LDAP server returns the OIDs in search results. Ciao, Michael. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
documentation updates
Hi,
The first patch removes an invalid LDAP option. The second updates the
LDAPObject documentation, and the third updates LDAPObject docstrings.
Hopefully I'll have time to look at updating the rest of the docs soon.
James Andrewartha
Index: Modules/constants.c
===
RCS file: /cvsroot/python-ldap/python-ldap/Modules/constants.c,v
retrieving revision 1.30
diff -u -r1.30 constants.c
--- Modules/constants.c 17 Jul 2007 19:37:27 - 1.30
+++ Modules/constants.c 23 Oct 2007 01:10:45 -
@@ -154,7 +154,6 @@
add_int(d,OPT_HOST_NAME);
add_int(d,OPT_ERROR_STRING);
add_int(d,OPT_MATCHED_DN);
- add_int(d,OPT_PRIVATE_EXTENSION_BASE);
add_int(d,OPT_DEBUG_LEVEL);
add_int(d,OPT_TIMEOUT);
add_int(d,OPT_REFHOPLIMIT);
Index: Doc/ldap.tex
===
RCS file: /cvsroot/python-ldap/python-ldap/Doc/ldap.tex,v
retrieving revision 1.30
diff -u -r1.30 ldap.tex
--- Doc/ldap.tex 27 Mar 2007 22:31:51 - 1.30
+++ Doc/ldap.tex 23 Oct 2007 01:10:45 -
@@ -120,8 +120,10 @@
\subsubsection{Options}
-For use with functions and method set_option() and get_option() the
-following option identifiers are defined as constants:
+To manage the behavior of python-ldap there are a number of options that can be
+set. For more details, see \manpage{ldap.conf}{5} and \manpage{ldap_get_options}{3}.
+The functions and method set_option() and get_option() use the following option
+identifiers, which are defined as constants:
\begin{datadesc}{OPT_API_FEATURE_INFO}
\end{datadesc}
@@ -136,6 +138,7 @@
\end{datadesc}
\begin{datadesc}{OPT_DEREF}
+ Specifies how alias derefencing is done when performing a search.
\end{datadesc}
\begin{datadesc}{OPT_ERROR_STRING}
@@ -157,6 +160,7 @@
\end{datadesc}
\begin{datadesc}{OPT_REFERRALS}
+ Boolean specifying if referrals should be automatically followed, defaults to \code{True}.
\end{datadesc}
\begin{datadesc}{OPT_REFHOPLIMIT}
@@ -300,9 +304,6 @@
The entry already exists. E.g. the \var{dn} specified with \method{add()}
already exists in the DIT.
\end{excdesc}
-\begin{excdesc}{}
-
-\end{excdesc}
\begin{excdesc}{AUTH_UNKNOWN}
The authentication method specified to \method{bind()} is not known.
\end{excdesc}
@@ -522,12 +523,17 @@
and wait for and return with the server's result, or with
\constant{None} if no data is expected.
-LDAPObject instances, have the following methods:
+Methods with `\constant{_ext}' (and some without) accept two extra arguments,
+\var{serverctrls} and \var{clientctrls} which are server and client controls.
+They can be constructed with the \refmodule{ldap.controls} module.
+
+LDAPObject instances have the following methods:
%%
%% abandon
\begin{methoddesc}[LDAPObject]{abandon}{msgid}
+ \methodline[LDAPObject]{abandon_ext}{msgid \optional{, serverctrls=\constant{None} \optional{, clientctrls=\constant{None
Abandons or cancels an LDAP operation in progress. The \var{msgid} argument
should be the message ID of an outstanding LDAP operation as returned by
the asynchronous methods \method{search()}, \method{modify()}, etc.
@@ -541,11 +547,13 @@
\begin{methoddesc}[LDAPObject]{add}{dn, modlist} % -> int
\methodline{add_s}{dn, modlist}
+ \methodline{add_ext}{dn, modlist \optional{, serverctrls=\constant{None} \optional{, clientctrls=\constant{None
+ \methodline{add_ext_s}{dn, modlist \optional{, serverctrls=\constant{None} \optional{, clientctrls=\constant{None
Performs an LDAP add operation. The \var{dn} argument is the distinguished
name (DN) of the entry to add, and \var{modlist} is a list of attributes to be
added. The modlist is similar the one passed to \method{modify()}, except that the
operation integer is omitted from the tuples in modlist. You might want to
-look into sub-module l\refmodule{ldap.modlist} for generating the modlist.
+look into sub-module \refmodule{ldap.modlist} for generating the modlist.
\end{methoddesc}
%%
@@ -573,19 +581,19 @@
\end{methoddesc}
%%
-%%
-\begin{methoddesc}[LDAPObject]{cancel}{
-cancelid,
-\optional{, serverctrls=\constant{None}
-\optional{, clientctrls=\constant{None
- Send cancels extended operation for an LDAP operation specified by \var{cancelid}.
- The \var{cancelid} should be the message id of an outstanding LDAP operation as returned
- by the asynchronous methods search(), modify() etc. The caller
- can expect that the result of an abandoned operation will not be
- returned from a future call to result().
- In opposite to abandon() this extended operation gets an result from
- the server and thus should be preferred if the server supports it.
-\end{methoddesc}
+%% cacncel is not implmenented
+%\begin{methoddes
