Hallvard B Furuseth wrote:
Howard Chu writes:
Ando and I tripped over this before, the solution was to compare the
be->be_private pointer.
I suppose it's possible that a backend (like back-null?) may have no
private data, so perhaps be_nsuffix is a better choice.
Back-null has private data. OTOH, back-passwd's be_private is only set
if it is configured with an alternate passwd file, otherwise it's NULL.
be->be_private need not be constant for the lifetime of a database:
back-ldap/chain.c and overlays/translucent.c modify it.
I have plenty of custom overlays that do modify it transiently. That's
one of the issues I was having when adding back-config capabilities to
back-ldap & slapo-chain.
back-monitor/monitor_back_db_open() reads be->be_private and stores
it back, even though it never changes it. I don't know why.
It'll be cleaned up some time. It was just, I guess, for consistency
with other backends.
I think there might be cases in which all of the generic backend stuff
gets changed for some reason, most likely during internal operations. I
wouldn't even trust be_suffix or be_rootdn (which might be NULL) or so.
What about adding a be_tag field to the BackendDB structure that is
unique (e.g. it gets some number from a given source when it's marked as
a new database) so that it's sticky even when copying a backend
structure into a temporary for internal operations? To feed it, one
could envisage a backendDB_tag(BackendDB *bd) function that is passed a
pointer to a backendDB structure and univoquely marks it. It would be
called by backend_db_init() for each database allocated via the
"database" config directive, but it could be called also directly to tag
internal databases (e.g. in slapo-pcache, slapo-translucent and so).
p
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
