[Fedora-infrastructure-list] LDAP Schema Proposal

Aurelien Bompard gauret at free.fr
Wed Aug 9 21:29:59 UTC 2006


> > There is some doc for python here :
> > http://python-ldap.sourceforge.net/docs.shtml
>
> Everything I look at has information on querying but nothing on schema
> creation and design.

True, schema creation and design is not really programming. Here's some good 
links about it:
http://www.ldapman.org/
http://www.skills-1st.co.uk/papers/ldap-schema-design-feb-2005/ldap-schema-design-feb-2005.html
http://yolinux.com/TUTORIALS/LinuxTutorialLDAP-DefineObjectsAndAttributes.html
ftp://ftp.isi.edu/in-notes/rfc2252.txt

> I'm beginning to think that LDAP is nothing like 
> SQL :-)

Yep, it's very different indeed.


> Are these accurate:
>
> Where SQL lets you associate pieces of data as the whim strikes you,
> LDAP has predetermined what pieces of data are relevant to each other.
> Your queries in LDAP are selecting these predetermined pieces of data
> which you then filter or make new queries to get more data.

Yes, AFAICT.

> There is no query language in LDAP.  Instead you have a set function
> interface that let's you interact with the server.

No, there is a query language, which is more of a query syntax actually. For 
example:
 - In SQL: SELECT uid FROM fedoraMembership WHERE cn = 'group1'
 - In LDAP : (&(objectClass=fedoraMembership)(cn=group1))
selecting only the uid attribute is not part of this syntax but it is always 
possible.

> Are there keys in LDAP?

There can be mandatory attributes in your schema (for example you uid is 
mandatory, but not your phone number)
You can define indexes to maintain in the config file to speed up your 
searches.

> Are there constraints (Entries into this field must be digits.  Entries
> into that field must be dates.  Entries into this field must follow this
> regexp)?

Yes. You can also define how it should match in a search (case-sensitive, 
space-sensitive, anything). See http://ldap.akbkhome.com and 
http://www.openldap.org/doc/admin23/schema.html#Attribute%20Type%20Specification

> Can you search by regexp?  Does this depend on the LDAP server?

No, searching depends on the type of match defined for your attribute.

> If there is no query language in LDAP, then that's probably a big reason
> why SQL people don't understand LDAP.  Even now, I'm trying to wrap my
> brain around the concept of a database without a query language but my
> gut just doesn't understand how that could be.

There is a query syntax. Keep in mind that LDAP is a tree. To search you 
need 4 things :
- the starting point (a branch or the top of the tree)
- the scope : only this entry (called "one"), the items right under this 
entry (called "base"), or all the subtree (call "sub")
- the list of attributes you want to retrieve from the entries you've found
- the search string itself : you search for entries having attributes 
matching your search. Examples :
  - (uid=toshio) : search for all entries with the uid attribute 
matching "toshio"
  - (&(sn=Kuratomi)(mail=*@tiki-lounge.com)) : search for all entries with 
the sn (SurName) attribute matching Kuratomi, and the mail attribute ending 
in @tiki-lounge.com.
  - and it could get more complicated when you add AND and OR requests.

There are two other things that are non-obvious to SQL people :
 - any entry can have a sub-entry. No concept of file != folder.
 - unless specified otherwise, every attribute can have multiple values.

I'm probably skipping many other specificities, but I hope it clears up the 
concept. If you have more questions, feel free to ask, I'm sure there's 
plenty of hardcore SQLers out there :)


Aurélien
-- 
http://aurelien.bompard.org  ~~~~  Jabber : abompard at jabber.fr
The only "intuitive" interface is the nipple. After that it's all learned.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20060809/fc249b9a/attachment.sig>


More information about the Fedora-infrastructure-list mailing list