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

["Mudry, Robert (N-aerotek)" <robert.mudry@lmco.com>]

>> 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 never said anything about "not sticking with" the standard. I am
QUESTIONING the standard.

>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.

Couldn't agree more. You're either compliant or you're not. If something
doesn't seem right, try to get the standard changed, don't just ignore it.
If Netscape followed the standard in the first place, I would have known
about these issues when I initially wrote the application and wouldn't have
had to go back and fix my code.

>I rely on Kurt that the OpenLDAP project does not try to mimique broken 
>behaviour of some "market-leading" directory server vendors.

Once again, I want to stress that I'm not in ANY WAY suggesting that
OpenLDAP do anything other than follow the letter of the standard perfectly.
I am suggesting that the letter of the standard, in my opinion, needs some
refinement in a few minor areas.

>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.

I don't necessarily agree. A character string is empty if it is null. It is
null if it is empty. Now I DON'T believe in treating null as the number
zero. If your attribute represents a number and you're trying to say you
have none of something, using an empty attribute is a little weird. But so
is just removing the attribute.

>> But for LDAP, this is not allowed?
>
>A non-existent attribute is simply not existent.

Yeah, but a null string is not a non-existent attribute, it is an empty
value. Or at least in my context, it is an empty string value. When you get
a credit application, do you use an exacto-knife to cut out the sections of
the form that don't apply to you? Maybe a poor analogy, but that situation
is as weird to me as being forced to delete the attribute just because the
value happens to be null.

 > 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.

You can't? How about this. Let's say a user fills out a form with two
attributes. I take the provided values and attempt to modify the associated
dn. What would you do? Excuse the pseudocode:

$ldap->modify( $dn, changes => [ replace => [ 'attrib_a' => $value_a ],
replace => [ 'attrib_b' => $value_b ] ] );

But what if the user decides to delete the value in attrib_a? I can no
longer use "changes". I now MUST address each attribute individually,
because I don't know if I need to do a replace or a delete for any of the
attributes.

So, if ( $value_a eq "") { # do delete } else { # do replace }. Of course,
with delete I need to check if it succeeded or failed, and if it failed, was
it because the attribute ALREADY doesn't exist? Or should I just ignore the
error code, and hope the failure wasn't because of something evil like the
connection broke. Of course, if the connection DOES break, I'm out of luck
anyway because without being able to use "changes" any hope of atomicity is
completely out the window.

THIS is my gripe. I think this is WRONG.

If you disagree on this still, then perhaps the behavior of replace should
be modified IN THE STANDARD to say "replace existing values of the given
attribute with the new values listed, creating the attribute if necessary,
*and deleting the attribute if the value is null*." or something like that.

I think this can be justified by the reasoning that REPLACE is already
assuming some behavior of ADD (creating the attribute if necessary).

>> 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.)

No, I was implying that I thought the part of the standard that says you
can't have a null value for an attribute was as silly as having
"favouriteDrink" as part of the schema. In other words, was it REALLY
necessary to include favouriteDrink in the track schema?

>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.

You could at least add a smiley to your personal jabs.

-Robert

> -----Original Message-----
> From:	Michael Ströder [SMTP:michael@stroeder.com]
> Sent:	Tuesday, April 02, 2002 5:39 AM
> To:	Mudry, Robert (N-aerotek)
> Cc:	'openldap-software@OpenLDAP.org'
> Subject:	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.