[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: "Replacing" an attribute's value with "nothing"

Mudry, Robert (N-aerotek) wrote: 
I think what can many times be forgotten is, there is a big difference
between what a standards body determines to be the right way of doings
thing, and what is truly practical from an implementation standpoint

If you decide to use LDAP you have to stick to the standard to get some added value out of it. Otherwise go for something different.

I'm somewhat sick of vendors claiming to support LDAP but implementing only broken vendor-specific code in their products. Personally I'm pumping my data into various LDAP servers for doing LDAP interoperability checks.

I'm not a member of the OpenLDAP project. But AFAIK OpenLDAP 2 is meant as a reference implementation of LDAPv3. For this purpose it's perfectly valid to be as strict as possible. If your application works with OpenLDAP it works most times also with other LDAP server implementations right out of the box. I rely on Kurt that the OpenLDAP project does not try to mimique broken behaviour of some "market-leading" directory server vendors.

for
mere mortals like myself who are trying to get some simple functionality out
of a system which, lightweight or not, is still pretty darn complex.

If you need something simpler and don't want to bother with complex standards then design your own simple access protocol. You will then be responsible for all the nits and bits of it.

For example, why can't I assign a value of null to an attribute? You can
vary the behavior of attributes in other ways (multivalue, case insensitive
string, etc.) but not "can be null"? It's not as if this is an unusual
concept in databases.

Robust RDBMS applications have to also properly check for null values anyway to show a well-defined behaviour. It's bad design to rely on null values being some meaningful default for non-existent data. Most times such applications are broken.

But for LDAP, this is not allowed? 

A non-existent attribute is simply not existent.

> Instead, I now need 
to write quite a bit of extra code and perform several different operations,
put additional load on the server, and add unnecessary complexity to my
application.

Frankly I can't see how checking for the existence of an attribute or properly check for null values differ in complexity of code.

Are the people who determined that you can't have a null attribute value the
same ones who decided that "favouriteDrink" (UK spelling and all) is a
necessary attribute in the cosine schema?

(I assume the "necessary attribute" means mandantory attribute in an object class.)
I've checked RFC1274, OpenLDAP 2 and Netscape DS 4.x schema. In every schema favouriteDrink alias drink (OID 0.9.2342.19200300.100.1.5) is not a mandantory attribute. Maybe you have the tendency not to read standards documents and configuration data carefully enough.

Ciao, Michael.