Re: back-config, includes

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Howard Chu writes:
>Hallvard B Furuseth wrote:
>> Exactly, so 5 comes after 10.  Problem solved:-) If you have entry {1}
>> and {2} and want to insert one between, create entry {15}.  No need to
>> rename, until the max supported number of digits (if any) is used up.
>>
>> If the numbers are kept in an integer variable, represent 153 as
>> 153000000 internally, strip trailing zeroes in string representation,
>> reject trailing zeroes in input values.
>
> That's nice because then it's identical to a lexical sort order, very
> easy to implement, but personally I think the result looks ugly and is
> difficult to interpret. When I see a listing with a column of variable
> width numbers it just looks "wrong" to me. Maybe it's just me...

OK.

>>> For single-valued attributes used as an RDN, adding the extension
>>> "X-ORDERED 'SIBLINGS'" to the attribute definition means to maintain
>>> the numeric index based on sibling entries with the same RDN
>>> attribute.
>>
>> I suppose an RDN can contain at most one attribute with the X-ORDERED
>> extension?
>
> That's as much as I've considered. I guess if you had multiple AVAs in
> an RDN they could all sort in combination,

I don't think so.  Remember that RDN components are unordered.  The
implementation could define an ordering, but then future versions would
be more or less locked to that ordering.

> but I haven't got a need for that here.


>>> dn: olcDatabase={1}bdb,cn=config
>>
>> One point: I suggest to use an attribute with a textual database
>> name chosen by the admin for the RDN rather than the attribute
>> which specifies the backend.  Then put the database's backend in
>> the 'olcBackend' attribute or something.
>>
>> That would make it easier to see what a set of modifications are
>> doing, and if one can say 'dn: olcDatabase=mail,cn=config' instead
>> of 'dn: olcDatabase={2}bdb,cn=config' there would be less risk of
>> accidentally modifying the wrong database if an earlier operation
>> renumbered the databases.
>
> That's a nice idea, but I don't see how to implement it for the
> migration case, where the entries are automatically constructed from
> slapd.conf.

I would generate it from the RDN of the database's first suffix, if it
has one: Un-escape its (first) attribute value, normalize and lowercase
it, replace or remove bad characters, truncate if too long.  If the
result is not good enough, fall back on the backend name.

> Or are you suggesting that we allow ModRdn to be used to
> change the automatically generated name to an admin-selected name?

Good point.  I suggest an optional 'databaseName' slapd.conf directive
which can be used to override the default name when converting to
back-config.

Whether generated or given by the admin, the name must probably be a
nice string to use for filenames: Matching ^[a-z][-_a-z0-9]{0,11}$ or
something.

> Also, the ordering component must still be preserved, regardless of a
> name change.

Yup, so it's no disaster if two databases end up with the same name.
It just means the admin will have to use the ordering component when he
needs to access the database configuration.

When a server's database names are unambiguous I suppose they could also
be used in some other contexts, like 'slapadd -n databasename'.

-- 
Hallvard