Re: Searching without matching derived attributes

[Quanah Gibson-Mount <quanah@stanford.edu>]

--On Monday, May 09, 2005 1:36 PM -0500 Digant C Kasundra <digant@uta.edu> 
wrote:

> > ># utaMailAlias -- email alias value
> > > attributetype ( 1.3.6.1.4.1.19638.1.1.102 NAME 'utaMailAlias'
> > > 	DESC 'Email alias'
> > > 	SUP mail)
> > >
>
> > Don't SUP it.  Use your OID for the NAME, and use the same SYNTAX as the
> > mail attribute. ;)
>
>
> Here is a theoretical question that I'll ask to see if someone has
> experience with it.  If I change the above attributetype definition, but
> currently have attributes of that type in my directory, will lead to
> problems?  I'm not familiar with the underlying structure used to store
> or index these attributes in the backend to know how to predict the
> results.  I'll likely err on the side of caution and remove then reload
> those attributes unless someone can assure me that it isn't necessary.

First, look and see if there is an utaMailAlias.bdb file (that would be its 
index file).  If there is you should be able to change the schema without 
affecting the database.  Just keep the same SYNTAX and matching rules as 
the mail definition.

We do something similar at Stanford:

attributetype ( 0.9.2342.19200300.100.1.3
       NAME ( 'mail' 'rfc822Mailbox' )
       DESC 'RFC1274: RFC822 Mailbox'
   EQUALITY caseIgnoreIA5Match
   SUBSTR caseIgnoreIA5SubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )


attributetype (1.3.6.1.4.1.299.11.1.800 NAME ( 'suMailDrop' )
   EQUALITY caseIgnoreIA5Match
   SUBSTR caseIgnoreIA5SubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )


We were SUPPING some attributes until we too hit this same issue and then 
converted. ;)

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html