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 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.
>
>There are alot of "mere mortals" trying to use powerful tools which they 
>do not properly understand.

Well, perhaps you would like to explain to me what I don't understand? My
impression is that LDAP is a protocol for accessing a directory service, and
a directory service is a database which contains information about people
and things in a read-optimized fashion. My webserver uses LDAP to manage its
users, and I use this existing LDAP directory to store additional
information about my users that is meaning to my application and my user
base. Where is the misunderstanding?

>>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.
>
>One might argue LDAP (OpenLDAP) isn't a database,  certainly not a 
>relational one.  If you trying to use a *directory* like you'd use a 
>database you simply have selected the wrong tool.  NULLs don't make sense 
>(to me anyway) for the problem domains LDAP was 'designed' to solve.

No, LDAP isn't a database. It's a protocol to access a directory, which is a
type of database with an emphasis on searches and reads. Though it seems to
me that if the LDAP specification is going to specify the directory's
schema, then it shouldn't be offended when people call it a database. There
is absolutely no mistaking it for a relational database, that's for certain!

So what problem was LDAP 'designed' to solve that I'm just not getting? I
always thought it was to allow many independent applications to access and
maintain information on certain entities, such as people, across one or more
organizations. What does the exact nature of the data have to do with
anything?

>>But for LDAP, this is not allowed? 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.
>
>Maybe rethinking the fundamentals of the application a bit might help 
>solve this problem. 

I don't think any sort of "rethinking" is going to solve the problem that if
I can't use a null as a valid value in an attribute, that I'm going to need
to do a delete of that attribute if no value is appropriate. Heck, I already
rewrote the offending routines; I'm now trying to understand what the real
issue is here, and what the exact nature of my ignorance is on this matter.

>A very strict data model is what makes LDAP so handy for integrating 
>disparate services (mail routing, authentication, certificate chains, 
>etc..)  A null certificate, mail servers, username just doesn't make any 
>sense?  How would sendmail deal with a user that had a mailhost attribute 
>that wasn't?  You have one or you don't,  that makes simple application 
>logic.  Verses A.) You don't have one, B1.) You have one but it isn't B2.) 
>you have one but it is.

If a null doesn't make sense for an attribute a particular application is
using, then why can't that application's attribute be defined as not
allowing nulls? Why should my application, which enjoys a good null from
time to time, not be allowed to have one because an application written 20
years ago doesn't want one in an attribute I'm not even touching? Or put
another way, why can't I define a schema for my application that contains an
attribute which accepts a null as a valid value? 

It's not like I am asking for a change to the standard track schemas. I'm
asking why my application, which requires some attributes of its own, can't
define those attributes in its own schema such that null is a valid value.
Just because it doesn't make sense to sendmail to have a null value for its
mailhost attribute?
[deleted a bunch of stuff]

I still don't believe I have a reasonable understanding why a null is a bad
thing in an attribute that my application defines.

-Robert

> -----Original Message-----
> From:	Adam Williams6 [SMTP:awilliam@whitemice.org]
> Sent:	Monday, April 01, 2002 12:13 PM
> To:	Oberwetter, josh
> Cc:	'Mudry, Robert (N-aerotek)'; 'openldap-software@OpenLDAP.org'
> Subject:	RE: "Replacing" an attribute's value with "nothing"
> 
> >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 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.
> 
> There are alot of "mere mortals" trying to use powerful tools which they 
> do not properly understand.
> 
> >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. 
> 
> One might argue LDAP (OpenLDAP) isn't a database,  certainly not a 
> relational one.  If you trying to use a *directory* like you'd use a 
> database you simply have selected the wrong tool.  NULLs don't make sense 
> (to me anyway) for the problem domains LDAP was 'designed' to solve.
> 
> >But for LDAP, this is not allowed? 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.
> 
> Maybe rethinking the fundamentals of the application a bit might help 
> solve this problem. 
> 
> A very strict data model is what makes LDAP so handy for integrating 
> disparate services (mail routing, authentication, certificate chains, 
> etc..)  A null certificate, mail servers, username just doesn't make any 
> sense?  How would sendmail deal with a user that had a mailhost attribute 
> that wasn't?  You have one or you don't,  that makes simple application 
> logic.  Verses A.) You don't have one, B1.) You have one but it isn't B2.)
> 
> you have one but it is.
> 
> >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?
> 
> ?  So don't use the favouriteDrink (UK spelling) attribute.  Someone at 
> the lumber company don't the street doesn't use any of the schema we've 
> defined, and I don't use any of theirs.
> 
> >I greatly appreciate all the hard work that has gone into the OpenLDAP
> >project. But I sometimes wish that LDAP itself was a little narrower in
> >scope, 
> 
> Seems you want to make it broader in scope (adding nulls)
> 
> >a little less complex, 
> 
> OpenLDAP compared to Informix Online or even Postgres is hysterically 
> simple.  Databases (real ones) have Constraints, foriegn keys, primary 
> keys, sequences, blobs, stored procedures, statistics, etc....
> 
> >and a little more understanding. 
> 
> A tight (and sometimes frustrating) data model is what makes LDAP so 
> useful in the first place.
> 
> >Is it only
> >me, or do all these standards bodies way overcomplicate the problems they
> >are trying to solve?
> 
> Oh, yes.  But I think SOAP and XML is a much better example than LDAP.
> 
> -- 
> -----------------------------------------------------------
> Ximian GNOME, Evolution, LTSP, and RedHat Linux + LVM & XFS
> -----------------------------------------------------------