[Date Prev][Date Next]
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.
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
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
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.