[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: commit: ldap/servers/slapd/tools slapcommon.c

> I think this fix (and possibly the prior code) is actually
> bad.
> slapcat -n N should exports the Nth database, period.
> slapadd -n N should import the Nth database, period.

I understand your point; but slapcat with no -n can be
intended as cat what's available.  the monitor backend
is something special, as the glue backend is: a trick
to exploit backend structure facilities in something
that's tightly built-in.  As a consequence, they're a
trade-off between exploiting what's there and inhibiting
what is not desired.

> If the user selects a database which doesn't (currently)
> support exporting/importing, an error should be returned.

agree: slapcat -n N where N is monitor is an error;
and it is still treated as an error after my fix.

> To do otherwise will lead to user confusion as its
> possible that a database could support exporting
> but not importing via slapadd (meaning slapadd -n N
> may not refer to the same database as slapcat -n N)
> or vice versa.

agree with confusion.  If you think this fix is more confusing
than helpful, please back it out :)  But note that, thanks
to slapcommon.c, we're guaranteed that automatic database
selection is the same for all tools (at least now).

> And support for importing/exporting may change over time.
> Today only a few backends support these functions,
> however nothing stops them from being more widely
> implemented.

It would not be the first time we stop supporting something
we did in the past; I mean: it's part of the game, to deprecate
what once was good.


Pierangelo Masarati